Re: Definition time macros

[willc%tekchips.tek.csnet@CSNET-RELAY.ARPA]

    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

        From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>

	    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
    
	        From: mike%gold-hill-acorn@LIVE-OAK.LCS.MIT.EDU
    
	        I'd like to see this tightened up to indicate that macros
		expand once, as in a compiler, and are not expanded over
		and over each time an expression is interpreted.
    
	    I feel very strongly that requiring this is a bad idea.

        I feel very strongly that requiring this would be a very good idea.
	I think Scheme has a big lesson to teach us here. They have made
	lexical analysis occur at a well-defined time and it has made
	program-understanding a much more straightforward issue.

    But they can't even agree among themselves what the semantics of macros
    should be!

It's useful to distinguish between agreement on what the semantics should
be, what the semantics will be, and what the semantics is.  The designers
of Common Lisp clearly don't agree on what the semantics of macros should
be, are trying to agree on what the semantics will be, and are fairly well
agreed on what the semantics is.  Thanks to Common Lisp, the designers of
Scheme felt free to worry about what the semantics should be instead of
worrying about a stopgap.

When Kent mentioned Scheme, he may have been thinking of the design
principle that the semantics of the language must make sense independently
of any strategies that might be used to implement it.  To paraphrase Guy
Steele:

    If, in the course of discussing a proposed language feature,
    such terms as "interpreter", "compiler", or "macro expansion
    time" come up, they serve as a warning!

For example, if a language feature doesn't make sense in an implementation
that doesn't have an interpreter, then the feature should be considered
only for inclusion in the programming environment section.  This is
analogous to saying that a language feature that doesn't make sense in
an implementation that doesn't have a garbage collector should be
included, if at all, only in the programming environment section.

If the semantics were defined so that macros were expanded only once, then
implementors of programming environments could:

    1.  Let users see the macro-expanded code.
    2.  Do the work necessary to keep users from seeing code they didn't
        write.  (There's a continuum between 1 and 2, fortunately.)
    3.  Expand macros multiple times and advertise the bug as a feature.

The main difference between this and the status quo is that the status quo
has such a poorly defined semantics that implementors can expand macros
multiple times and advertise the bug as a feature without having to admit
that it's a bug.  Neat trick.

William Clinger
Tektronix Computer Research Laboratory