[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Potential issue: MACRO-SPECIAL-FORMS
- To: firstname.lastname@example.org, email@example.com
- Subject: Potential issue: MACRO-SPECIAL-FORMS
- From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
- Date: Thu, 23 Feb 89 22:00:42 GMT
There's a problem that's been bothering me from time-to-time, and
I would like to have it cleared up one way or another. I've actually
mentioned it several times in the context of other issues, but it
never caught on.
I won't put it in official issue format yet, but I am certainly
willing to do so. One problem is that I'm not sure whether the right
forum is Cleanup or Compiler.
On page 57, CLtL explains that the list of special forms is kept small
"because any program-analyzing program must have special knowledge
about every type of special form." It goes on to say "Such a program
needs no special knowledge about macros because it is simple to expand
the macro and operate on the resulting expansion."
Indeed, although an implementation is permitted to implement as a
special form any construct described by CLtL as a macro, it is
required to provide "an equivalent macro definition" [also p 57].
However, the implementation note on page 58 explicitly allows the
macro definition to produce an expansion that contains implementation-
dependent special forms, thus making the requirement for an equivalent
macro an empty one.
Consequently, program-analyzing programs are not promised anything of
Remove the permission granted by the implementation note on page 57.
Require that the macro expansion of any construct described as a macro
in Common Lisp not contain any implementation-specific special forms.
A secondary problem:
The implementation note on page 58 claims "there is no problem
with a macro expansion containing calls to implementation-dependent
Unfortunately, that is not quite true. For example, a special form
(sf . args) might expand to (do-an-sf '(sf . args)), where do-an-sf
is an implementation-dependent function. Such functions are
essentially special forms in disguise.
A program-analyzing program learns nothing of value from such an
Not quite a Proposal:
This one is harder, because it is difficult (and perhaps impossible?)
to precisely characterize the class of acceptable functions.
The basic goal is that the intent of the macro definition should be
evident in the expansion. Subexpressions of the macro call that are
identified syntactically as forms should appear as forms in the
expansion, variables should appear as variables, and so on. But we
can't say they must appear only as forms, variables, and so on; so
it's not clear that the goal is an attainable one. There are
presumably other problems as well.
Consequences of non-adoption:
We would have to say that program-analyzing programs potentially
require (and therefore, to be portable, require) special knowledge
about every construct described as a special form or as a macro
in the definition of Common Lisp.
I would like to eliminate the first problem even if we can't
handle the second.