HL Legal Specifications: Base System
hl base system is composed of three layers.
<axiom>The Axiomatic layer. The axiomatic layer may be considered as equivalent to the classic Lisp basemost axioms, implemented directly in
eval. The compiler included with each compliant
hlvirtual machine should support these members.
<common>The Common layer. This includes certain basic operations whose actual implementation may vary between
hlvirtual machines, and yet may be generically useful among concrete implementations of the final layer below.
<hl>The Standard layer. This is the standard
hllibrary. It is expected that the library will be useful and efficient enough that users will directly use the standard
hllibrary without having to descend to the lower layers, Common and Axiomatic.
Each layer defines symbols with particular meanings. The symbols
in each layer must have specific prefixes:
<common> for Common, and
<hl> for Standard.
In addition to these prefixes, a fourth prefix,
reserved for implementation-specific purposes. An
implementation may use symbols with this prefix for any purpose.
Because it is implementation-specific, users of any
should be aware that use of
<impl> symbols ties them to the
Symbols for each Layer
<axiom> are all special forms, i.e. the
implementation's compiler should recognize them immediately and
compile them to their equivalent bytecodes. In particular,
macros that are assigned to these symbols's global variable slot
will be ignored by the compiler.
<common> are all global variables with function
contents. The users of
hl cannot rely on certain functions in
<common> to be serializable or portable; the result of
(<common>disassemble (<common>code-of _)) may be
is one of the non-serializable function from
other words, a function in
<common> might not be implemented
<hl> are all global variables with function or macro
contents. All contents of
<hl> are specified as being
serializable and portable.
Coupling of Axiomatic and Common
We expect to have tight coupling between the Axiomatic and Common
layers, such that an implementation may include extensions to
these specifications, provided that these extensions are used only
in the implementation of Common, and will not be used by Standard.
For instance, Common includes a function to determine if a symbol
begins with a the character
<, and has a character
elsewhere; it is legitimate for an implementation to implement
this in the Axiomatic layer as a special form.
Most functions in Common are expected to be implementable using only the specified Axiomatic. However, an implementation can legitimately implement Common in the underlying implementation directly, particularly if this is significantly more efficient than using Axiomatic. Care must be taken that injections will not be able to see these extensions in action.
Some functions in Common are known to be unimplementable using only Axiomatic. Such functions can only be implemented using extensions to the specifications; one requirement is that such functions cannot be interrupted (i.e. injecting a function into a process will not find such functions running or runnable).
it is not yet concrete, at this time, whether or not injecting a process - i.e. forcing a process to execute code that is not part of its normal flow - will be added to the specifications. the main problem is that this is effectively an interrupt, which is hard to reason about. in any case, such injections might destroy the conceptual integrity of message passing.
Reserved Axiomatic and Common
<common> that are not specified are
reserved for future versions of the specifications. However,
current implementations using the current version of the
specifications are allowed to use these symbols internally as
extensions, provided those extensions do not become part of
portable bytecode sequences. In particular, a continuation
provided by a
<common> function to user code cannot contain
references to these extensions; such continuations should
It should be understood, however, that an implementation should be prepared to change its extensions when a new version of these specifications defines a name used in its extension.
All functions and macros in Standard are expected to be implementable using only the specified Common and Axiomatic. However, an implementation cannot legitimately implement Standard in the underlying implementation directly, or by extensions to Common and Axiomatic.
If a specified Standard function cannot be implemented using only
Common and Axiomatic, it should be considered an error in the
specifications. Please report such errors to the
The decoupling of the Common and Axiomatic layers from Standard
exists so that users of
hl, the language, may fork the Standard
library to change various portions of the interface, without
having to reimplement significant portions of Common, and to be
able to rely on tight coupling between Axiomatic and Common for