Potential issue: MACRO-SPECIAL-FORMS

[Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>]

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.

Problem:

  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
  value.

Proposal:

  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
  functions."

  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
  expansion. 

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.

-- Jeff