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

Active Versions Section

The Versions keyword begins the active versions section. The contents of this section are zero or more string literals separated by commas , (U+002C). Each string literal corresponds to a version of the API that the module pledges to support. Versions are specified as arbitrary strings to allow developers to adopt different versioning taxonomies for their products.

Module "HTML" Versions "3.2", "4.0", "4.01", "5.0" Names /* API goes here… */ Body

The appearance of a version within the active versions section constitutes a promise of backward compatibility to downstream modules that explicitly request this version in an import specification. In the example above, the hypothetical HTML module promises to support four different versions of its API.[1]

Module "Web Crawler" Versions "2.0" Uses "HTML" ("2.0", "3.2") Names /* API goes here… */ Body

Now consider the hypothetical module Web Crawler. It imports HTML in its private imports section, and declares a requirement for either version "2.0" or version "3.2" of the API. HTML declares that it supports version "3.2", but does not mention version "2.0". Because there is a version in common between the promise and the requirement, the compiler permits the import and proceeds with compilation.

Because Web Crawler declares a dependency on version "3.2", it should not discover at compile time that the compiler rejects sends of messages that were present when version "3.2" of HTML was brand new. Nor should it discover, at run time, that the semantics of operations imported from HTML are now different (and incompatible) with those which it expects and requires.

Unfortunately, neither the compiler nor the executor are able to ensure the sincerity of a promise of backward compatibility; it would be extremely difficult, if not impossible, to declare the exact nature of the syntactic and semantic drift between two versions of an API using a generic model that could be mechanically checked. Ensuring that an older version of a module is still well supported by its present implementation is therefore the responsibility of the module's developers.

On the other hand, this mechanism allows the module to declare quite sincerely, by omission, that a version is not supported. Consider version "1.0" of Web Crawler:

Module "Web Crawler" Versions "1.0" Uses "HTML" ("1.1", "2.0") Names /* API goes here… */ Body

When the compiler processes the import of HTML, it discovers that versions "1.1" and "2.0" are not supported. It blocks compilation by issuing an error message like this:

[PARSE]: module "/website/Modules/Versions/1.0/Web Crawler", line 40: >>> 33: Module "Web Crawler" >>> 34: Versions "1.0" >>> 35: Uses >>> 36: "HTML" ("1.1", "2.0") >>> 37: Names >>> 38: /* API goes here… */ >>> 39: Body >>>--------------------------------------------------------------------- >>> Expected... >>> version compatibility; module "HTML" guarantees versions {"3.2", "4.0", "4.01", "5.0"} but the current module requires {"1.1", "2.0"} (file="/website/Modules/Versions/1.0/Web Crawler", line=40) >>>---------------------------------------------------------------------

[1] It is hoped that these versions correspond to published versions of the HTML standard, but of course it is not possible for the Avail compiler to require this!

‹ Entry Points Section | Return to Modules | Private Imports Section ›