-(

[Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>]

    Date: Sat, 11 May 1985  09:35 EDT
    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>


    Upon reflection, I shouldn't have been so flippant in dismissing BSG's
    suggestion about macro-expansion environments, and I apologize to him.

Thankyou.  I thought your assessment was in fact unduly harsh.  The
criteria for judging this kind of suggestion should include, "Does it
solve the problem?" "Does it create new problems?"  "Does it bother
things other than the thing it was designed to address?" "Given that it
addresses some hairy need, will you have to deal with it unless you have
that hairy need?"  "Is it consistent in design and philosophy with the
rest of the language?"  "Is it straightforward to explain?" "Is
efficient implementation obvious?"  I think that the general idea
of my suggestion meets these (admittedly self-supplied) criteria.

    I assume that his suggestion was serious, and poking fun at suggestions
    that we disagree with is obviously not the best way to promote the free
    flow of ideas.  It has been a long week, and I was feeling irritable.
Thankyou.  I hope you feel better.
    I think that this suggestion is a step in the wrong direction.  We want
    to make the whole issue of macros expanding in funny places less
    confusing, not more so, and a multiple name space mechansism so that
    macros in various places can have the same name doesn't look to me like
    a good idea.
(what follows is sort of rambling...)

Any better than the "declaration 'functions'" (like STRING in the
preceding conversation) having the same name as a real function?   Why
isn't the set of those things extensible?  Remember in MacLisp they
actually WERE functions?  I suppose macros there worked! I wonder if
anyone actually ever exploited that!

But now we are above that, and we have asserted that the declaration
namespace is in fact divorced from the function namespace.  There
already -is- this multiple namespace.  As there should be.  Why isn't a
macro paradigm within that namespace reasonable?  OK, don't use
defmacro, say
  (putprop 'my-decl #'my-decl-expander :declaration-macro) for all I care,
if my syntax is too bizarre.  It seems as though it's that very capability
that you don't like.  

I would like to dredge up an elegant feature of LAP (remember those?) on
Multics, which, if it encountered a symbol marked as a Lisp Macro
name-symbol, as the CAR of an instruction specification, it would apply
the macro-function to the instruction specification, and assemble the
returned list of instructions in place.

This is a typical, potent, and elegant use of "the Lisp Macro concept"
to extend operator sets embedded in the Lisp Language.  -Surely-, if I
had thought along these lines back then, we would have some different
kind or option of DEFMACRO (which didn't even exist per se) for defining
LAP macros in this way.

DEFMACRO provides three things for you:
  1) A way to define a -LISP FUNCTION- to be called by the evaluator
     and compiler at certain highly specific times and contexts.
  2) A way to define a Lisp function of one argument which has
     built-in syntactic shorthands for destructuring and structure-verifying
     that argument.
  3) A -conceptual- ability, a paradigm, for extension of the language via
     transformation of code fragments.

2 & 3, esp. 3, are obviously, by the cited examples, useful in a wide,
extensible variety of contexts other than "evaluation/compilation of
Lisp forms".  Clearly, I can put in replacements for (1) (e.g., DEFLAPMACRO)
all I want, in any program I want (does this invoke your objection of
"macros expanding in funny places?").  There is nothing in the language
to prevent me, or even discourage me from doing this.  In fact,
I think it is something to encourage.

Having said that, why is the notion of the Language providing hooks of
-some kind- for extensibility via transformation (a euphemism, if you like),
at other points where the symbol CAR of a form is significant (e.g., LAMBDA,
declarations, type specs.....) not reasonable?