Re: how expressive are they?

[Daniel Weinreb <address@hidden>]

Trevor Blackwell wrote:

>What I'd like to see is an example of a program, in a language with easy
>syntax for assignment and blocks, where rewriting it without any
>user-defined macros would be similarly painful.
>
The "define-xxx" macros, which Scott McKay explained in earlier mail, is 
one class of such
examples.  They get interesting when you have big and complex systems. 
 The Zmacs
macro for defining a new Zmacs command expanded into about six things, 
which you
would otherwise have had to write out, six times, for each command.  It 
would be easy
for someone to forgot to write one of the six. Another example in the 
Lisp machine
("Genera") software system was the macro for defining "commands" in the 
Lisp machine's
"command processor".  It is hard for me to give brief and convincing 
descriptions of
these because (a) they are only compelling precisely because they are 
parts of large
systems that take a long time to describe, and (b) it has been over 15 
years since I
have taken a look at them.

There was another define-xxx macro that was important to me: the one used to
define persistent classes in my first object-oriented database system, 
Statice.
It was something along the lines of


(define-persistent-class employee (:oneoption expr1 :anotheroption expr2)
   (:inherits-from person)
   (my-department (department :one-to-one))
   (my-badge-number :integer)
    ...)

or something.

Have any of you ever seen the language used to define attributes and 
objectclasses for an LDAP
database?  That could be expressed in Lisp macros as well.

Outside of the define-xxx class (and LOOP) I am having a hard time 
remembering
examples, but if I had the Genera code base at hand, I bet I could find 
some.  Is
anybody out there sitting at a Lisp machine with sources?

I do agree that macros are big guns, and if you have two ways of doing 
something,
and they are different along various dimensions, and you are reckoning 
cost-benefit
for each dimension and adding up all those cost-benefits to get an 
overall cost-benefit,
then in the function-vs-macro dimension, the cost of being a macro 
instead of a function
is quite large.  In other words, if a function will do, you should 
usually use a function
instead of a macro, except in extreme circumstances.

I also agree that a lot of what Lisp macros were used for can be done 
with closures,
particularly if the syntax for closures is succinct enough that 
verbosity does not
become an annoyance.  While I am not as big a succinctness fan as some 
of us,
I am convinced that extreme succinctness for closures is worthwhile.

I don't think we're going to make much progress talking about small 
examples like
IF and :ifNotNil or whatever.  Macros are a heavy-duty tool for 
heavy-duty jobs.

-- Dan