Potential issue: MACRO-SPECIAL-FORMS

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Thu, 23 Feb 89 22:00:42 GMT
    From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>

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

This part is not true and weakens your earlier point (which I think is
well-taken).  For example, the implementation of Flavors used by Cloe
uses a code-walker to implement SYMBOL-MACROLET and that code-walker is
written entirely in portable Common Lisp.  What is important to that
code walker (and a whole class of code walkers like it) is that it know
what parts of something are `evaluated normally,' what parts are
`evaluated specially,' and what parts are `not evaluated.' For example,
if UNWIND-PROTECT were not a standard special form but was added by some
implementation with a macroexpander that turned
  (UNWIND-PROTECT (FOO) (BAR))
into
   (SI::UNWIND-PROTECT-FUNCTION #'(LAMBDA () (FOO))
				#'(LAMBDA () (BAR)))
this would be fine. While you're right when you say I don't "learn" anything
 from examining the latter form, you're wrong when you fail to observe that
I can `walk' the latter form reliably, while I cannot walk the former.

The reason this is so is because no function in Common Lisp is prohibited
 from doing magic things that no user could ever possibly hope to write.
That shouldn't be so surprising. After all, it's not just my function above
that has this property, but also other usually-seen-as-ordinary functions
like OPEN or CAR. I can't write them in Common Lisp either, after all.

Certainly there are applications that need to have a deeper understanding
of what special forms do, but there's really no hope for such applications.
Indeed, such applications probably have to have specialized knowledge about
DO as well -- and cannot even depend on its macro expander to provide "insight".

    ...
    I would like to eliminate the first problem even if we can't
    handle the second.
    ...

I suggest that to do this you should drop the second cause so that arguments
against it don't end up detracting from the first.

By the way, in considering the alternatives, please keep in mind that another
possible solution (besides disallowing macros expanding into implementation-specific
special forms) is to define a code-walker interface and facility for extending same
so that extending the language to have new special forms doesn't cause a breakdown
in the ability to do code-walking. I think it's reasonable to describe this as
beyond the scope of what we have time or resources to do at this point, but I
wouldn't want mention of the option to be omitted altogether.