Re: Using Macros in Lisp

[Tom McDougal <mcdougal@gargoyle.uchicago.edu>]

dmg@goldilocks.lcs.mit.edu writes:
 > Avoiding any language extension is like avoiding the emergency brake
 > in your car.  The facility is there for a reason, use it when you need
 > to (...)

Spoken like a true Common Lisp man. :-) I'm a Scheme fan myself,
not usually interested in using all the bells and whistles the
committee crammed into Common Lisp.  Even w/ a memory as feeble
as mine, there is something wrong when I have to look in the
reference manual to understand my own code because I made use of
some obscure albeit appropriate feature.

 > In the first example, we have a macro that at best replaces a type
 > check that is directly supported by the language (and thus possibly
 > directly supported by the compiler).
 > 
 > INSIST = CHECK-TYPE in Common Lisp

Thank you!  I did not know about this function.  Another gentle
reader suggested that INSIST = ASSERT, another function I didn't
know about and which looks closer to the mark.  I do not know how
I would have found out about CHECK-TYPE or ASSERT w/out the aid
of this group, since requests to the local CL hackers failed to
turn up either of them.

You are correct that, in the example I used, CHECK-TYPE would be
more appropriate.  Please accept that I chose the example for its
simplicity, and not because it represents a best use of INSIST.
In most cases the argument checks I want to perform are more
special-purpose than a type check.  I certainly intend to learn
more about CHECK-TYPE and ASSERT and incorporate them into my code.

 > ----------------
 > In the second example, there are a few problems.
 >    (...comments on the innapropriateness of the name "iterate"
 >     for someting clearly recursive, etc...)

 > 	If you want to "march down a list until you find something"
 > 		use FIND -- That's why its there.

I didn't know about this function, either.  Actually, I usually use my
ITERATE special form to cons up a list.  I chose the name ITERATE
because that's what the T language designers called it, and
because people "speak" T around here.

 > 4) Personally, I would argue that there's no need for a macro here
 >    at all.

Certainly not.  By the same token, there's no need for lots of CL
features that can be got at via more primitive functions.  It's a
matter of providing a convenient syntax.  But that's a major
reason we use macros, isn't it?

 >    ...Importing semantically redundant features from other 
 >    languages is difficult to justify, except on the basis of
 >    personal preference.
     ^^^^^^^^^^^^^^^^^^^^^
I claim nothing else.

 >    If you're going to write something in Common 
 >    Lisp, which other people who use Common Lisp are likely to want to
 >    read, why confuse them with redundant constructs from a language they
 >    may have never used?

Am I getting flamed here?  Sorry!  I do not flatter myself that
anyone else will want to look at most of my code.  In general,
however, I agree with you.  I use a minimum of macros, I stick
close to vanilla Common Lisp As I Know It (clearly a limited
subset of the entire language :-), and document heavily, because
when I come back to my code months later it's not easy to
remember what I was thinking and what macros it relied on.

The original poster wanted help w/ macros.  I tried to help by
providing macros which
   a) I actually use
   b) are fairly simple.  The examples were chosen to be
*extremely* simple, not representative of how I use them.  I
apologize if I have confused anyone, especially the original
poster.

--- begin tangent: ----
 > Try this:
 > 
 > 	(defun fact (x)
 > 	  (let ((result x))
 > 	    (loop
 > 	      (if (= (decf x) 1)
 > 		  (return result)
 > 		  (setq result (* result x))))))
 > 
 > I would expect that most compilers will have a hard matching this
 > code, and are not going to do better.  If the compiler does not
 > implement tail-recursion and use special entry-points for internal
 > functions, you're going to lose quite badly.
 >

(I saw your later correction to this--no matter)

This interests me from the (opposing?) points of view of style
and compiler efficiency.  Stylistically, I try to avoid side-
effects.  The above looks like C or Pascal translated into CL.  I
also always wondered what SETQ looks like at the machine-level.
Is it really very efficient?

--- end tangent ----

Although I was a little hurt by the apparent flame, I appreciate
your informative message.

   --Tom  (mcdougal@cs.uchicago.edu)

	2025, Edgar Spindizzy realizes that
	his time machine works.