Differences

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

--- language:namespaces [2020/05/01 16:47]
rajit [Opening namespaces]
+++ language:namespaces [2022/05/13 08:46] (current)
rajit
@@ Line 12: / Line 12: @@
 A namespace is created by using the ''namespace'' construct.
-<code>
+<code act>
 namespace lib {
 ...
@@ Line 38: / Line 38: @@
 namespaces is shown below.
-<code>
+<code act>
 namespace datapath {
     export defproc bus_interface(...) { ... }
@@ Line 64: / Line 64: @@
 the entire namespace ''adder'' can be exported as follows:
-<code>
+<code act>
 namespace datapath {
     export defproc bus_interface(...) { ... }
@@ Line 93: / Line 93: @@
 The basic form of import statement is shown below:
-<code>
+<code act>
 import "channel.act";
 ...
@@ Line 106: / Line 106: @@
    * ''$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
@@ Line 157: / Line 111: @@
 hierarchy. The import statement
-<code>
+<code act>
 import processor::lib;
 </code>
@@ Line 163: / Line 117: @@
 is equivalent to the following:
-<code>
+<code act>
 import "processor/lib/_all_.act";
 </code>
@@ Line 169: / Line 123: @@
 It assumes that the file ''_all_.act'' in the directory
 ''processor/lib'' contains all the definitions corresponding to the
-''processor::lib'' namespace.
+''processor::lib'' namespace. More precisely, an 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 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 =====
@@ Line 177: / Line 143: @@
 To resolve this issue, ACT provides a way to rename a namespace that has been imported.
-<code>
+<code act>
 import "lib1.act";
 open lib -> lib1;
@@ Line 195: / Line 161: @@
 because not all types might be exported! In this case we can say:
-<code>
+<code act>
 import "lib.act";
 open processor::lib;