Commit 65526a4a authored by Michael Raskin's avatar Michael Raskin

Syncing from Monotone at 20190426-024704. Last commit message was A note about...

Syncing from Monotone at 20190426-024704. Last commit message was A note about not requiring too much
parent a24fd04c
......@@ -2,7 +2,7 @@ Motivation
The Common Lisp standard describes a lot of facilities for treating code as
data. Unfortunately, it stops short of specifying enough functionality to
allow writing a portable code walker. In addition, some requirements that
allow writing a portable code walker. In addition, some requirements that the
might have been assumed to be implications of the standard are not spelled out
explicitly. As a result, implementations have different behaviour, which
creates more corner cases than necessary for partial code walking
......@@ -12,22 +12,6 @@ Some of the functionality useful for code walkers has been described in the
second edition of «Common Lisp: the Language» as included in the standard, but
later removed.
Libraries like ITERATE, CL-CONT, PETALISP, etc. provide functionality that
relies on code walking, but have to resort to imperfect solutions for
performing code walking. It is probably very hard to implement
standard-compliant DEFMACRO, MACROEXPAND-1 and COMPILE (even without producing
native code) without an internal implementation of all the functionality
necessary for code walking. Most implementations provide access to that
functionality to user code. Unfortunately, the exact package and symbol names
differ, and can change between releases of the same implementation.
This document proposes a unified set of names so that existing and future
implementations can provide their preferred flavour of environment handling
functionality in a way that can be probed without assumptions about behaviours
of specific implementations. Adoption of uniform names will allow creation of
portability libraries without the need to keep track the exact versions of
implementations that change the environment object representation.
This document defines three sets of requirements, CDR-NN-a, CDR-NN-b, and
CDR-NN-b. The first set of requirements is intended to be easy to implement and
maintain. The goal is to provide easy and uniform detection and use of the
......@@ -38,11 +22,7 @@ smart enough macro» stories to reality. The third set of requirements permits
more efficient implementation of code walkers, while only using the
functionality many implementations are expected to have internally.
«Requirements of CDR-NN» is synonymous with «requirements of CDR-NN-a». The
«SHALL» requirements defined inside CDR-NN-b and CDR-NN-c are mandatory only
for compliance with the corresponding sets of requirements and MAY be violated
by an implementation claiming only CDR-NN-a compliance. Note that CDR-NN-a
compliance is enough to detect CDR-NN-b and CDR-NN-c compliance.
«Requirements of CDR-NN» is synonymous with «requirements of CDR-NN-a».
The uniform naming requirements (CDR-NN-a).
......@@ -70,13 +50,13 @@ declarations as described in CLtL2.
PARSE-MACRO — this symbol names a function for processing macro definitions
like defmacro does as described in CLtL2.
ENCLOSE — this symbol names a function for processing an anonymous function
ENCLOSE this symbol names a function for processing an anonynmous function
definition in a (compile-time) lexical environment as described in CLtL2.
BLOCK-INFORMATION — this symbol names a function that accepts a block name and
an optional environment, and returns the :BLOCK keyword if blocks are tracked
in the environment object and a block with the provided name is listed, and
NIL otherwise.
an optional environment, and returns :BLOCK if blocks are tracked in the
environment object and a block with the provided name is listed, and NIL
otherwise.
TAG-INFORMATION — this symbol names a function that accepts a tag name and an
optional environment, and returns :TAG if tags are tracked in the environment
......@@ -120,7 +100,7 @@ LEXICAL-ENVIRONMENT — this symbol names a type that includes all possible
non-NIL values of &environment parameter to macros defined via DEFMACRO or
MACROLET. The type SHOULD be as narrow as feasible.
Additionally, implementations MAY provide :CDR-NN-EXPANSIONS in *features*. In
Additionally, implementation MAY provide :CDR-NN-EXPANSIONS in *features*. In
this case, the following constraints SHALL hold.
A compliant implementation SHALL provide macro definitions for all operators
......@@ -152,24 +132,21 @@ but with an additional macro expansion provided that returns
(labels ((f (x) (1+ x))) (function f))
Safe code walking support requirements (CDR-NN-b).
Full code walking support requirements (CDR-NN-b).
An implementation that is compliant with CDR-NN-b SHALL implement CDR-NN-a,
SHALL satisfy the :CDR-NN-EXPANSIONS requirements and SHALL provide at least
the following functionality as defined in CDR-NN-a requirements.
A compliant implementation SHALL implement CDR-NN-a, SHALL satisfy the
:CDR-NN-EXPANSIONS requirements and SHALL provide at least the following
functionality as defined in CDR-NN-a requirements.
Either WITH-AUGMENTED-ENVIRONMENT, or AUGMENT-ENVIRONMENT, or
ENVIRONMENT-ENTRY-NAMES, or MACROEXPAND-ALL.
Efficient and complete code walking support (CDR-NN-c)
Efficient code walking support (CDR-NN-c)
An implementation that is compliant with CDR-NN-c SHALL implement CDR-NN-b and
SHALL provide at least the following functionality as defined in CDR-NN-a
requirements.
A compliant implementation SHALL implement CDR-NN-b and SHALL provide at least
the following functionality as defined in CDR-NN-a requirements.
Either WITH-AUGMENTED-ENVIRONMENT or AUGMENT-ENVIRONMENT.
ENVIRONMENT-ENTRY-NAMES.
PARSE-MACRO.
LEXICAL-ENVIRONMENT.
DECLARATION-INFORMATION.
DEFINE-DECLARATION.
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment