Differences

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

--- language:namespaces [2020/05/01 16:44]
rajit [Importing namespaces]
+++ language:namespaces [2020/12/02 01:00]
127.0.0.1 external edit
@@ 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
-First, duplicate namespaces might exist, especially when re-using old
+ACT files be placed in locations that match the namespace
-files. For instance, suppose we have two files: ''lib1.act'' and
+hierarchy. The import statement
-''lib2.act'' both containing namespace ''lib'', but having
-definitions that are useful. Importing both would result in the union of
+<code>
-the namespaces, and could create naming conflicts (e.g. multiple
+import processor::lib;
-definition of types having the same name---an error). To solve this
+</code>
-problem, one can do the following:
+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. 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 =====
+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 files, potentially resulting in errors.
+To resolve this issue, ACT provides a way to rename a namespace that has been imported.
 <code>
@@ Line 123: / Line 150: @@
 </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
@@ Line 148: / Line 173: @@
 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.
+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.
-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 =====