ERR5RS:Optional extension: Library phases
From SchemePunks
Contents |
[edit] Overview
ERR5RS only mandates syntax-rules macros, leaving support for low-level macros to optional extensions. An optional extension to the library syntax to manage import phases useful in low-level macros will be described here.
[edit] Extension to library syntax
The following extension to the library syntax described on the page ERR5RS:Libraries is required:
<import spec> ::= <import set> ; same as (for <import set> run)
| (for <import set> <import level> ...)
<import set> ::= <library name>
<import level> ::= run ; same as (meta 0)
| expand ; same as (meta 1)
| (meta <integer>)
[edit] Import levels
Here should be a simple definition of what it means for an identifier reference to be at a particular level.
- Rationale for import levels:
- The meaning of program that references bindings only at their declared levels is invariant under compilation in the following sense: One will obtain the same results whether one expands and evaluates the forms constituting the libraries sequentially in an interpreter, or first expands the whole sequence and then evaluates it.
- Implementations can use level information to apply various optimizations preserving the instantiation semantics, as well as to optimize and manage resources at different phases of incremental compilation.
[edit] Correctness criterion
A correct ERR5RS program satisfies the following criteria:
- No imported binding is referenced outside its declared import levels.
- No local binding is referenced outside the level in which it is bound.
- All macro transformers are pure functions in the following weak sense: No preexisting locations are mutated by invoking a transformer, and the output of a transformer may only depend on locations that are by convention never mutated after instantiation of the library that allocates them.
Writing correct programs is the programmer's responsibility, although implementations are encouraged to raise errors when they can determine that a program is incorrect.
Issue: Maybe this is too restrictive. Consider instead using the R6RS characterization (or a more precise one derived from it).
[edit] Semantics
The semantics for instantiating an ERR5RS library using for is exactly the same as the semantics for instantiating a library not using for, copied from ERR5RS:Libraries:
- If the library has already been instantiated, do nothing. Otherwise
- Instantiate all the libraries imported by the library in some unspecified order.
- Evaluate the definitions (including macro definitions) and expressions of the
<library body>s in sequence, after effectively renaming all non-imported identifiers in the library to avoid conflicts with identifiers in other libraries or in the top level, and effectively renaming all imported identifiers to refer to their bindings in their defining libraries.
Since the store is never mutated as far as ERR5RS macro transformers are concerned, the question of whether or not instantiations and bindings are shared between phases becomes meaningless. The stated semantics assumes that they are shared.
