Commit 38edaee3 authored by Michael Raskin's avatar Michael Raskin

Merge branch 'master' into 'master'

Typos and Comments

See merge request !2
parents 05f8d916 af8ea524
......@@ -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 the
allow writing a portable code walker. In addition, some requirements that
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,6 +12,12 @@ 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?
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
......@@ -50,11 +56,11 @@ 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 anonynmous function
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
an optional environment, and returns :BLOCK if blocks are tracked in the
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.
......@@ -100,7 +106,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, implementation MAY provide :CDR-NN-EXPANSIONS in *features*. In
Additionally, implementations 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
......@@ -150,3 +156,7 @@ 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.
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