Commit 1526f2da authored by Michael Raskin's avatar Michael Raskin

Syncing from Monotone at 20190330-223529. Last commit message was

parents
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 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
implementations.
This CDR defines two sets of requirements, CDR-NN-a 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 functionality
implementations already provide under implementation-specific names. The
second set of requirements requires some additional work from implementations,
but provides a way to move some advanced functionality from «a smart enough
macro» stories to reality.
Implementation MAY claim compliance with CDR-NN if they implement the CDR-NN-a
requirements.
The uniform naming requirements (CDR-NN-a).
A compliant implementation SHALL provide :CDR-NN-A keyword in *features* and
CDR-NN package (this package MAY have a different name and CDR-NN nickname).
The CDR-NN package SHALL contain a subset of the symbols described in the
current section. Each provided symbol SHALL name a function or a constant
conforming to the specification in the current section.
Full code walking support requirements (CDR-NN-b).
An implementation claiming compliance with CDR-NN-b SHALL also comply with
CDR-NN-a. It SHALL provide :CDR-NN-B keyword in *features*. It SHALL implement
the following functionality defined in the previous section:
A compliant implementation SHALL provide macro definitions for all operators
defined as macros in the standard. Expansion of conforming (portable) code
SHALL be conforming code that MAY use some implementation-specific functions.
The expansion SHALL NOT pass non-portable arguments to standard operators.
For every form in the original code, this form or the result of expanding some
macros inside the form SHALL be a form of the expansion.
Examples of discouraged behaviours permitted by the Common Lisp standard.
(defun f (x) (1+ x))
is currently allowed to expand to any of the following:
(define-function 'f '(lambda f (x) (block f (1+ x))))
(define-function 'f (impl::named-lambda f (x) (block f (1+ x))))
(define-function 'f "x -> (1+ x)")
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