Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!mit-eddie!genrad!decvax!decwrl!labrea!Shasta!andy
From: andy@Shasta.UUCP
Newsgroups: comp.lang.lisp
Subject: Re: Against the Tide of Common LISP
Message-ID: <1284@Shasta.STANFORD.EDU>
Date: Tue, 17-Feb-87 03:24:52 EST
Article-I.D.: Shasta.1284
Posted: Tue Feb 17 03:24:52 1987
Date-Received: Tue, 17-Feb-87 22:45:39 EST
References: <2581@well.UUCP> <2582@well.UUCP>
Reply-To: andy@Shasta.UUCP (Andy Freeman)
Organization: Stanford University
Lines: 43

In article <2582@well.UUCP> jjacobs@well.UUCP (Jeffrey Jacobs) writes:
>You know perfectly well that interpreting macros takes more time!
>First you have to EVAL the form, and then give the result to EVAL
>again!  (And I *don't* consider it kosher to destructively expand
>without the user's control).

It is possible to cache the result of macro expansion without
destructively modifying user code.  If this technique is implemented
correctly, this cache is flushed appropriately when a macro is redefined
(or changed to a function).  In other words, speed is the only difference
between using this technique and re-expanding the macro anew each time the
relevant code is eval'd.

If one is slightly more clever, one can apply a variation of this
technique to function bodies and perform some other analysis at the
same time so that interpreted code runs fairly fast.  (No, you don't
have to do it when the function is first called.  There are other
opportunities.)  Of course, you have to do this right or it gets in
the way of debugging, but ....

I'm sure that major CL vendors use better techniques than I can come
up with in 10 minutes.

I've forgetten why JJ is so down on macros; doesn't "real" lisp have
them?

>    Certainly *parts* of [Common Lisp] can be implemented in itself;
>why should they then be considered a critical part of the language that
>can't be done without?

Every lisp dialect that I've written non-trivial programs in (Interlisp,
Maclisp, Franz, T) predefines forms that I could have defined myself using
other forms.  This is good.  I prefer to build on other people's work;
Turing machine programming is so tedious.  Since CL is not a minimal
language, each vendor can choose a different core and implement the rest
of the language using it.  This too is good; it leads to higher performance.

-andy
-- 
Andy Freeman
UUCP:  ...!decwrl!shasta!andy forwards to
ARPA:  andy@sushi.stanford.edu
(415) 329-1718/723-3088 home/cubicle