Re: Potential issue: MACRO-SPECIAL-FORMS

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

Kent --

Either you misunderstood what I said, or I failed to state it with
sufficient clarity.  I was not trying to say that *all* implementation-
dependent functions in macro expansions (of constructs documented as
macros in CLtL) are bad, but rather that *certain kinds of functions*
are.  So the CltL claim that "there is no problem" with functions is
wrong, and I was hoping that we might be able to rule out the bad
functions while keeping the good ones.

It was not my goal to eliminate calls to all functions that do "magic
things that no user could ever possibly hope to write", because, as
you point out, many "usually-seen-as-ordinary" functions have that
property.  Rather, I wanted to deal with the possibility that an
implementation might satisfy the letter of the law but nonetheless, by
using functions and quoted arguments instead of out-and-out special
forms, still make it impossible for code-walkers and the like to
reliably find all the forms in an expression.	

>    Date: Thu, 23 Feb 89 22:00:42 GMT
>    From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
>      For example, a special form (sf . args) might expand to
>      (do-an-sf '(sf . args)), where do-an-sf is an implementation
>      -dependent function.  
>      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).

Well, consider my example with 'sf' instantiated to UNWIND-PROTECT
(which isn't defined as a macro and so isn't really a proper instance
of the problem), and 'args' to ((FOO) (BAR)).  You write:

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

I agree that this is fine.  But suppose it expanded (as in my example)
to:

    (DO-AN-UNWIND-PROTECT
      '(UNWIND-PROTECT (FOO) (BAR)))

That is not fine.  I don't think anything in CLtL rules it out,
and I have seen things like it in at least one implementation.

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

I meant "learn" to be interpreted rather loosely.  The result is not
a useful one, because everything is hidden inside the QUOTE and so
would be ignored by a code-walker.

> For example, the implementation of Flavors used by Cloe uses a
> code-walker [...]  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.'

I agree about what is important.  I was trying to say something
similar in the "not quite a proposal":

  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.

-- Jeff