RE: Using Macros in Lisp

[Kevin Gallagher <Gallagher@gilgamesh.cs.umass.edu>]

 lynch@aristotle.ils.nwu.EDU writes:
 >   
 > I've always found it useful to think of macros as glorified
 > #define (is that it?) in /c...
 >   

I agree with this.  If Lisp texts presented them in that light then
many macro problems would be avoided.  C macros have many of the same
problems as Lisp macros: multiple evaluation of arguments, failure to
isolate the macro from the surrounding environment.  Of course, Lisp
macros are more flexible than C macros so you can get yourself into
more trouble with them.

Also note that because C doesn't have a notion of inline functions
there are often both macro implementations and function
implementations for a given operation.  e.g., getc vs. fgetc.  This
is clearly a Bad Thing.
    
 > Don't write a macro UNLESS:
 >
 > A: You have to. (e.g. a class assignment)
 >
 > B: It will be used in LOTS of places in your code and will save you
 >    LOTS of typing and make the code a LOT clearer.  (e.g. (with-open-file..))

I would say if it makes your code a lot clearer then do it regardless
of whether or not it also saves you typing or is used in lots of
places.  Anything that makes your code clearer is a win.

 > C: You NEED the arguments to be unevaluated so you can process them BEFORE
 >    you do the function.
 > (e.g.  (defmacro frame (name) `(find-frame ',name)))
    
What about this example requires it to be a macro?  Is it so you
can type (FRAME DOG) rather than (FIND-FRAME 'DOG)?  This is not
convincing to me.

 > D:  You are going to save a LOT of run-time cycles by computing something.
 > (e.g.  (defmacro slot-value (type object slot-name)
 >            ;...hairy computation of integer result deleted...
 >           `(svref (node-vector ,object) ,result))
 > )
    
Mumble.  Yes, although the cases where you will have enough
information to do that at compile time are very few.  If I really
want to do something like that use `#.' (eval at read time).

 > E:  You need to be able to setf some portion of a structure.
 > (e.g. (setf (slot-value person *fred* name) "Fred"))

I'm not sure what this is doing.  Will slot-value expand into a
structure accessor, so that the and the setf form expands into this:

  (setf (person-name *fred*) "Fred")
    
This is also a very limited situation because it will only work when
you know the slot name and type of the object at compile time.  If
that's the case then there is very little difference between

  (slot-value person *fred* name)

and

  (person-name *fred*)


Kevin Gallagher