[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Using Macros in Lisp
- To: email@example.com
- Subject: Re: Using Macros in Lisp
- From: Tom McDougal <firstname.lastname@example.org>
- Date: Wed, 6 Mar 91 13:04:12 CST
> 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
--- begin tangent: ----
> Try this:
> (defun fact (x)
> (let ((result x))
> (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.
2025, Edgar Spindizzy realizes that
his time machine works.