The Avail Programming Language
Mobile Users: Click here to view our text rendering warning.

Canonical Names

In addition to the local name, every module also has a canonical name. The canonical name is a module root-relative logical name. A module's canonical name comprises a solidus / (U+002F), then a module root name, then zero or many solidus-separated local names of enclosing packages, then a solidus, then the module's local name:

Consider the following file system structure:

/avail Avail.avail/ Advanced Math.avail/ Data Abstractions.avail/ Foundation.avail/ Bootstrap.avail/ Bootstrap.avail Error Codes.avail Fallible Primitives.avail Infallible Primitives.avail Origin.avail Primitives.avail Special Objects.avail IO.avail/ Unit Testing.avail/ Avail.avail

This is an abridged file system snapshot of the avail module root. The local name of the source module Infallible Primitives.avail is Infallible Primitives, and its canonical name is /avail/Avail/Foundation/Bootstrap/Infallible Primitives. A module package representative is treated as having the same canonical name as its enclosing package. Therefore the canonical name of the Bootstrap.avail representative is /avail/Avail/Foundation/Bootstrap.

The canonical names of modules never appear in a module header. Import targets, such as are found in the private imports and extended imports sections, must be specified as local names. The programmer is forbidden from using a canonical name to specify an import target. This is a design point of Avail, and is not intended as a limitation, but rather a transfer of responsibility from the programmer to the system.[1] This does not absolve the programmer of all responsibility, however, because the programmer still has the obligations of:

  1. Correctly placing the modules into the file system in the first place so that they can be discovered at all.
  2. Understanding how the compiler or executor resolves local names to modules.
  3. Providing a suitable module renames file in the rare event that the programmer wishes to bypass the usual module resolution mechanism for a few specific cases.

[1] In most traditional programming languages, the burden of locating an import target falls to the programmer, who often has to supply a fully-qualified logical path.

‹ Module Discovery | Return to Modules | Module Renaming ›