Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wilson
From: wilson@cs.utexas.edu (Paul Wilson)
Newsgroups: comp.lang.scheme
Subject: Re: Macros
Message-ID: <1492@yoakum.cs.utexas.edu>
Date: 29 May 91 15:54:47 GMT
References: <1490@yoakum.cs.utexas.edu> <JINX.91May29102934@chamarti.ai.mit.edu>
Organization: U Texas Dept of Computer Sciences, Austin TX
Lines: 68

In article <JINX.91May29102934@chamarti.ai.mit.edu> jinx@zurich.ai.mit.edu writes:
>
>    With respect to other features (e.g., multiple value returns), it
>    may well be that they should be left out of the core language, and
>    made optional.  But macros are so important that their basic
>    functionality MUST be part of the standard language.  (Fancy features
>    such as complex pattern matching might be made optional.)
>
>Although I realize that macros are a political necessity while
>multiple values are not, I disagree that macros are technically more
>necessary than multiple values.  
>
>I use multiple values in my everyday coding much more frequently than
>I use macros.  

I hadn't meant to disparage multiple values, or commit to a position
that they're less important in some deep sense.  I'm agnostic about
multiple values.  I think we agree that macros are a political necessity.

>You may want to argue that macros are more primitive or essential,
>since multiple values can be emulated in user code, while macros cannot,
>but to this I will reply:
>
>- A multiple value facility that meshes with cwcc and has various
>other expected properties cannot be trivially emulated in user code.
>
>- You can write your own macro pre-processor (similar in use to cc's
>cpp), and pre-process your files before loading them.  All the
>primitives are already there.

   I agree that you can preprocess anything into anything.  Part of my
point is that it's not all that hard to actually put macros in the compiler;
at least, it's easier than doing a whole prepass that does all of the
scope analysis, then feeding it to a compiler where much of that work
is replicated.

>I also disagree strongly with the attitude "approve anything now, even
>if it is crufty".

That was not the tone I indended.  I think that something could be approved
now in a basic form, without it being crufty, and refined later.  All I'm
asking for is *one* little bit of syntax to allow me to declare a simple
run-of-the-mill macro, without compicated pattern matching or list
manipulation.  The fancier features can be worked out later if necessary.

(This is analogous to making the (define <name> <value>) syntax standard
before making the procedure-defining  (define (<name> . <args>) ...) form
standard.  You can write portable programs with the former, though the
latter is nice, too.)

If the committee wants to decide that the "basic" and "initial" specification
of the macro facility *must* be lexically scoped, I'd be very happy with
that, and I think that's probably the way to go.  But even if that issue
was left unsettled (behavior undefined when scope rules clash), I think it
would be better than what we've got now.

(This is analogous to the distinction between #f and '().  It was not
standard at first, but you could write portable programs if you were careful.)

I just think we've waited long enough for macros.  People should be able to
write real, portable programs NOW without having to include their own
preprocessor to do macros.

On the other hand, if there are really serious technical obstacles to
defining a least-common-denominator macro facility, I'd be interested
in hearing them.

   -- Paul