Skip to content
GitLab
Projects
Groups
Snippets
/
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
Menu
Open sidebar
Michael Raskin
cdr-walkability
Commits
a24fd04c
Commit
a24fd04c
authored
Apr 25, 2019
by
Michael Raskin
Browse files
Clarifications in reponse to comments
parent
38edaee3
Changes
1
Hide whitespace changes
Inline
Side-by-side
walkability.txt
View file @
a24fd04c
...
...
@@ -12,11 +12,21 @@ 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.
// Comment PM: Which features would we actually want? Is that about
providing better LOOP and ITERATE, for better macro debugging, ...?
What do implementations already provide here? Could we get by with some
TRIVIAL-WALKABILITY library and very small patches to the implementations?
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
...
...
@@ -28,7 +38,11 @@ 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».
«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.
The uniform naming requirements (CDR-NN-a).
...
...
@@ -59,10 +73,10 @@ like defmacro does as described in CLtL2.
ENCLOSE — this symbol names a function for processing an anonymous 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
// Comment PM: what about (BLOCK NIL ...)?
an optional environment, and returns :BLOCK if blocks are tracked
in the // We need two return values.
environment object and a block with the provided name is listed, and
NIL
otherwise.
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.
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
...
...
@@ -138,25 +152,24 @@ but with an additional macro expansion provided that returns
(labels ((f (x) (1+ x))) (function f))
Full
code walking support requirements (CDR-NN-b).
Safe
code walking support requirements (CDR-NN-b).
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.
A
n
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.
Either WITH-AUGMENTED-ENVIRONMENT, or AUGMENT-ENVIRONMENT, or
ENVIRONMENT-ENTRY-NAMES, or MACROEXPAND-ALL.
Efficient code walking support (CDR-NN-c)
Efficient
and complete
code walking support (CDR-NN-c)
A compliant implementation SHALL implement CDR-NN-b and SHALL provide at least
the following functionality as defined in CDR-NN-a requirements.
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.
Either WITH-AUGMENTED-ENVIRONMENT or AUGMENT-ENVIRONMENT.
ENVIRONMENT-ENTRY-NAMES.
PARSE-MACRO.
LEXICAL-ENVIRONMENT.
// Comment PM: Why do we define various levels (-a, -b, -c) if the things
in them are declared as "SHALL"? IMO that means that every implementation
conforming to -a already conforms to -c as well.
DECLARATION-INFORMATION.
DEFINE-DECLARATION.
Write
Preview
Supports
Markdown
0%
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment