Modules and Imports

ENG modules are .eng files. A module is loaded and executed in its own VM; its resulting global bindings are made available to the importing program.

Import everything

Suppose math_helpers.eng contains:

Define a function called square that takes x and returns x multiplied by x.
Define a function called double that takes x and returns x multiplied by 2.

Then another file can use:

Import math_helpers.

Print Run square with 5.
Print Run double with 5.

The module name is resolved as math_helpers.eng.

Selective import

Import named bindings:

From math_helpers use square.

Multiple names are supported:

From math_helpers use square and double.

Resolution

For a module named math_helpers, the loader first checks:

<directory containing the importing .eng file>/math_helpers.eng

It then checks directories listed in ENGLING_PATH.

ENGLING_PATH is split using both ; and : by the current implementation, so paths can be supplied in either common style.

Exports

There is no explicit export keyword in v0.1.0. Top-level globals created by the module are collected as its exports.

In practice, top-level function definitions are the normal way to expose reusable functionality.

Caching and circular imports

Loaded modules are cached. A circular import is detected and reported as a module error instead of recursing indefinitely.

Missing modules

If the loader cannot find <name>.eng, the runtime reports a module error including the path it tried.