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
language:namespaces [2020/05/01 16:44]
rajit [Importing namespaces]
language:namespaces [2022/05/13 08:46] (current)
rajit
Line 12: Line 12:
 A namespace is created by using the ''namespace'' construct. A namespace is created by using the ''namespace'' construct.
  
-<code>+<code act>
 namespace lib { namespace lib {
 ... ...
Line 38: Line 38:
 namespaces is shown below. namespaces is shown below.
  
-<code>+<code act>
 namespace datapath { namespace datapath {
     export defproc bus_interface(...) { ... }     export defproc bus_interface(...) { ... }
Line 64: Line 64:
 the entire namespace ''adder'' can be exported as follows: the entire namespace ''adder'' can be exported as follows:
  
-<code>+<code act>
 namespace datapath { namespace datapath {
     export defproc bus_interface(...) { ... }     export defproc bus_interface(...) { ... }
Line 93: Line 93:
 The basic form of import statement is shown below: The basic form of import statement is shown below:
  
-<code>+<code act>
 import "channel.act"; import "channel.act";
 ... ...
Line 107: Line 107:
  
  
-There are a few things that might create issues in such a situation+A second version of import uses namespaces directly, but requires that 
-Firstduplicate namespaces might exist, especially when re-using old +ACT files be placed in locations that match the namespace 
-filesFor instancesuppose we have two files: ''lib1.act'' and +hierarchyThe import statement 
-''lib2.act'' both containing namespace ''lib'', but having + 
-definitions that are useful. Importing both would result in the union of +<code act> 
-the namespacesand could create naming conflicts (e.g. multiple +import processor::lib; 
-definition of types having the same name---an error). To solve this +</code> 
-problemone can do the following:+ 
 +is equivalent to the following: 
 + 
 +<code act> 
 +import "processor/lib/_all_.act"; 
 +</code> 
 + 
 +It assumes that the file ''_all_.act'' in the directory 
 +''processor/lib'' contains all the definitions corresponding to the 
 +''processor::lib'' namespace. More preciselyan import statement 
 + 
 +<code act> 
 +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 unsuccessfulreport an error 
 + 
 +After the import, the specified namespace is checked to see if it exists. If not, an error will be reported. 
 + 
 + 
 +===== Opening namespaces ===== 
 + 
 +If there are two different files that define the same namespace (say defined in multiple projects), importing both the files may result in type conflicts. Consider a scenario where we have two ''lib'' namespaces defined for two different projects, but  both have useful circuits that we would like to re-use in a third project. If ''lib1.act'' and ''lib2.act'' both contain namespace ''lib'', importing both would take the union of the definitions in the two filespotentially resulting in errors
 + 
 +To resolve this issueACT provides a way to rename a namespace that has been imported.
  
-<code>+<code act>
 import "lib1.act"; import "lib1.act";
 open lib -> lib1; open lib -> lib1;
Line 123: Line 150:
 </code> </code>
  
-The ''open'' construct enables one to rename a namespace. Once this +In this example, the ''open'' construct enables one to rename a namespace. Once this 
-has occured, there cannot be any naming conflicts. This version of +has occured, there cannot be any naming conflicts. This version of ''open'' is a renaming construct; after the open statement, the old name for the namespace is eliminated.
-''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 A second issue is one that is more about convenience. Consider a
Line 136: Line 161:
 because not all types might be exported! In this case we can say: because not all types might be exported! In this case we can say:
  
-<code>+<code act>
 import "lib.act"; import "lib.act";
 open processor::lib; open processor::lib;
Line 148: Line 173:
 namespace, not just the ones that are exported (including types within namespace, not just the ones that are exported (including types within
 nested namespaces). Note that this ''open'' statement will fail if nested namespaces). Note that this ''open'' statement will fail if
-all types cannot be uniquely resolved. +all types cannot be uniquely resolved. Note that the sequence of ''open'' and ''import'' statements can only be
- +
-The sequence of ''open'' and ''import'' statements can only be+
 at the beginning of an ACT file. at the beginning of an ACT file.
- 
-A second version of import uses namespaces directly, but requires that 
-ACT files be placed in locations that match the namespace 
-hierarchy. The import statement 
- 
-<code> 
-import processor::lib; 
-</code> 
- 
-is equivalent to the following: 
- 
-<code> 
-import "processor/lib/_all_.act"; 
-</code> 
- 
-It assumes that the file ''_all_.act'' in the directory 
-''processor/lib'' contains all the definitions corresponding to the 
-''processor::lib'' namespace. 
- 
-===== Opening namespaces ===== 
- 
- 
-