Skip to content

Latest commit

 

History

History
137 lines (110 loc) · 5.67 KB

imports.md

File metadata and controls

137 lines (110 loc) · 5.67 KB
Raw
layout title category tags order
developer-doc
Imports and Exports
syntax
syntax
imports
modules
4

Imports and Exports

In order to properly modularise and work with Enso code, the language provides a robust mechanism for importing code from modules, and also re-exporting that code from modules.

Qualified Names

Both imports and exports require the use of qualified module names. A qualified name consists of the library namespace (usually organization under which its published) and the library name, followed by module names mirroring the source tree of the library. For example the file src/Stuff/Things/Util.enso inside the library My_Lib published by the user wdanilo would have the following qualified name: wdanilo.My_Lib.Stuff.Things.Util. To facilitate library renaming (or deciding on the publishing organization later in the development cycle, or working on a project that won't be published) it is possible to use the keyword project instead of namespace and project name, to import a file in the same project. Therefore, the file src/Varia/Tools/Manager.enso in My_Lib published (or not) by wdanilo may use project.Stuff.Things.Util to refer to the previously mentioned file.

Import Syntax

There are two main ways of importing a module into the current scope.

Qualified Imports

These imports consist of the word import followed by a qualified name of a module. This can by optionally followed by the as word, and a referent name of the module as it should be visible in the importing scope.

The only name brought into scope by such an import is the name of the module (or the name provided after the as keyword, if provided).

Unqualified Imports

Unqualified imports are broken up into three main categories:

  1. Unrestricted Imports: These import all symbols from the module into the current scope. They consist of the keyword from, followed by a qualified module name, followed by an optional rename part (using the as keyword), then the keywords import all. For example: 
    from Standard.Base.Data.List as Builtin_List import all
  2. Restricted Imports: These import a specified set of names for use as automatically resolved referent names. They consist of the keyword from, followed by a qualified module name (with optional as-rename), then the word import followed by a coma-separated list of referent names to be imported. For example: 
    from Standard.Base.Data.List import Cons, Nil
  3. Hiding Imports: These are the inverse of restricted imports, and import all symbosl other than the named ones. They consist of the from keyword, followed by a qualified module name (with optional as-rename), then the words import all hiding, followed by a coma-separated list of referent names to be excluded from the import. For example: 
    from Standard.Base.Data.List import all hiding Cons, Nil

Imports in Enso may introduce ambiguous symbols, but this is not an error until one of the ambiguous symbols is used in Enso code.

Export Syntax

In order to allow for easy composition and aggregation of code, Enso provides its users with a mechanism to export imported elements from modules. They appear in Enso as follows:

Qualified Exports

These exports consist of the word export followed by a qualified name of a module. This can by optionally followed by the as word, and a referent name of the module as it should be visible in the exporting scope.

The only name brought into scope by such an export is the name of the module (or the name provided after the as keyword, if provided).

Unqualified Exports

Unqualified exports are broken up into three main categories:

  1. Unrestricted Exports: These export all symbols from the module into the current scope. They consist of the keyword from, followed by a qualified module name, followed by an optional rename part (using the as keyword), then the keywords export all. For example: 
    from Standard.Base.Data.List as Builtin_List export all
  2. Restricted Exports: These export a specified set of names, behaving as though they were redefined in the current scope. They consist of the keyword from, followed by a qualified module name (with optional as-rename), then the word export followed by a coma-separated list of names to be exported. For example: 
    from Standard.Base.Data.List export Cons, Nil, from_vector
  3. Hiding Exports: These are the inverse of restricted exports, and export all symbols other than the named ones. They consist of the from keyword, followed by a qualified module name (with optional as-rename), then the words export all hiding, followed by a coma-separated list of names to be excluded from the export. For example: 
    from Standard.Base.Data.List export all hiding from_vector, Nil

In essence, an export allows the user to "paste" the contents of the module being exported into the module declaring the export. This means that exports that create name clashes must be resolved at the export site.

Visibility of Export Bindings

Bindings exported from a module X are available in an identical fashion to bindings that are defined in the module X.