Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Last revision Both sides next revision
language:namespaces [2020/05/01 16:47]
rajit [Opening namespaces]
language:namespaces [2020/12/02 01:00]
127.0.0.1 external edit
Line 106: Line 106:
    * ''$ACT_HOME/act'': This path is used for system ACT files, shared across multiple projects.    * ''$ACT_HOME/act'': This path is used for system ACT files, shared across multiple projects.
  
- 
-There are a few things that might create issues in such a situation. 
-First, duplicate namespaces might exist, especially when re-using old 
-files. For instance, suppose we have two files: ''lib1.act'' and 
-''lib2.act'' both containing namespace ''lib'', but having 
-definitions that are useful. Importing both would result in the union of 
-the namespaces, and could create naming conflicts (e.g. multiple 
-definition of types having the same name---an error). To solve this 
-problem, one can do the following: 
- 
-<code> 
-import "lib1.act"; 
-open lib -> lib1; 
-import "lib2.act"; 
-open lib -> lib2; 
-</code> 
- 
-The ''open'' construct enables one to rename a namespace. Once this 
-has occured, there cannot be any naming conflicts. This version of 
-''open'' is a renaming construct. The old name for the namespace is 
-eliminated. 
- 
-A second issue is one that is more about convenience. Consider a 
-project that has many different people working on it, each in their 
-own namespace to avoid naming conflicts. This situation can result in 
-very long type names. Plus it would be more bookkeeping to have to 
-create a test environment for the types within, say, 
-''processor::lib''---not just because of the long type names, but 
-because not all types might be exported! In this case we can say: 
- 
-<code> 
-import "lib.act"; 
-open processor::lib; 
- 
-a1of2 d; 
-</code> 
- 
-This version of the ''open'' directive has two 
-functions: (i) it adds ''processor::lib'' to the search path for 
-types, and (ii) it allows one to access all types within the 
-namespace, not just the ones that are exported (including types within 
-nested namespaces). Note that this ''open'' statement will fail if 
-all types cannot be uniquely resolved. 
- 
-The sequence of ''open'' and ''import'' statements can only be 
-at the beginning of an ACT file. 
  
 A second version of import uses namespaces directly, but requires that A second version of import uses namespaces directly, but requires that
Line 169: Line 123:
 It assumes that the file ''_all_.act'' in the directory It assumes that the file ''_all_.act'' in the directory
 ''processor/lib'' contains all the definitions corresponding to the ''processor/lib'' contains all the definitions corresponding to the
-''processor::lib'' namespace.+''processor::lib'' namespace. More precisely, an import statement 
 + 
 +<code> 
 +import foo; 
 +</code> 
 + 
 +would do the following: 
 +  * Look for ''foo/_all_.act'' using the search paths specified earlier; 
 +  * If unsuccessful, then look for ''foo.act'' 
 +  * If unsuccessful, report an error 
 + 
 +After the import, the specified namespace is checked to see if it exists. If not, an error will be reported. 
  
 ===== Opening namespaces ===== ===== Opening namespaces =====