Module System

Module System Overview

As of the Gorgie release, Links contains a basic(-ish) module system.

Main features:

• In-file modules
• Multi-file modules
• Partially- and fully-qualified name resolution

Command line arguments

As some kinks may not yet be worked out, modules are disabled by default. To enable them, use the -m flag. Without the -m flag, files containing modules, fully-qualified names, or import statements will not compile, and will exit with an error.

Additionally, --path=/path1/to/import:path2/to/import will look for included modules in:

• /path1/to/import
• path2/to/import

Example Use

a.links:

open B
foo()

b.links:

module C {
  fun bar() { .. }
}
fun foo() { C.bar() }

Implementation

The module system works by resolving names to fully-qualified names, and flattening out modules to standard bindings. As an example, b.links would become:

fun B.C.bar() { .. }
fun B.foo() { B.C.bar() }

To do this, there are two extra passes that we need:

1. chaser.ml: Finds all files that need to be included, resolving necessary dependencies.
2. desugarModules.ml: Performs name resolution, removing modules and qualified names, replacing them with renamed binders and renamed plain variable names.

Chaser is called from frontend.ml, and is immediately followed by desugarModules.ml.

The pipeline afterwards is unaffected.

Future Work

• Signature files
• Optimisations
• Better integration with prelude loading. Ideally the prelude would be handled as part of the module system as opposed to a special case.
• Caching of imported modules (which is unsupported at present)