Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!munnari.oz.au!bruce!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.scheme
Subject: Re: Macros
Keywords: macro, extend-syntax, lexical scope, standards
Message-ID: <6055@goanna.cs.rmit.oz.au>
Date: 31 May 91 08:47:54 GMT
References: <1490@yoakum.cs.utexas.edu>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 70

In article <1490@yoakum.cs.utexas.edu>, wilson@cs.utexas.edu (Paul Wilson) writes:
> I respectfully differ with the "open letter" about Scheme.  In particular,
> macros *must* be standardized if Scheme is to survive.  Of all the
> barriers to using Scheme, this one's probably the easiest to fix.

There are two ways of doing that.  One way is to standardise a "low cost"
approach.  The other way is to come up with a really clean macro system
that correctly handles free variable capture and is even more general
than extend-syntax.  If you see Scheme as "Lisp lite", you'll prefer the
"low cost" approach.  If you see Scheme as "Lisp RIGHT", you'll prefer
the "extend-syntax with macro hygiene" approach.

Every one of the Schemes currently available to me (or whose manual I have
read) provides at least one interface to "low cost" macros, some several.
Accordingly, my code uses 
	(define-macro (id arg... [ . arg ]) ...body...)
because I have implementations of that for the Schemes I care about.
(I do not have an up to date manual for MacScheme, so I don't know whether
the restriction that "it is impossible to define a macro that will expand
into a top level 'define' special form that MacScheme will recognize as
such" still applies".  That's something I particularly want them for, sigh.)

I appreciate that this has problems, but it's a long way better than
nothing, and I think it would have been appropriate for the standard
to have included define-macro OR (macro <id> <expander-fn>), I don't
really _care_ which.  There could have been a warning:  "This will be
superseded by a much better approach".

There is at least one really neat proposal around for "macros done right".
I don't think that it will make existing Schemes much bigger than they
already are, with the notable exception of things like Elk and Scm.  (TI
PC Scheme isn't being maintained anyway.)

> I do not think it is terribly important that Scheme be extremely small;

You would if (a) you were using it as an extension language, and (b) you
had a lot of students trying to use it all at once on a UNIX system.

> it is more important that it is Done Right.

Yes, it's important that it be done right.  But old kludges may
be allowed to hang around.  Scheme still has set-cdr! and string-set!

> I would also like to point out that a lexically-scoped macro facility
> needn't be all that complicated.  A decent Scheme compiler is a
> nontrivial piece of work anyway

Yes, but there are useful implementations of Scheme that do not have
a compiler.

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

My basic gripe about things like extend-syntax is that it seems absurd
to me to provide a complicated pattern language for macros, yet provide
no pattern matching at all for ordinary code.  I am thinking about
writing a macro (!) that compiles a pattern-case form along the lines
described in Peyton-Jones, so that one could write

	(define (concat x y)
	    (pattern-case x
		(()		y)
		((,h . ,t)	`(,h . ,(append t y))) ))

Does that sound useful?  I could post the draft spec for criticism.
-- 
Should you ever intend to dull the wits of a young man and to
incapacitate his brains for any kind of thought whatever, then
you cannot do better than give him Hegel to read.  -- Schopenhauer.