Newsgroups: alt.lang.design,comp.lang.c++,comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!fs7.ece.cmu.edu!kinky.eng.gtefsd.com!europa.eng.gtefsd.com!howland.reston.ans.net!pipex!uknet!festival!edcogsci!jeff
From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Subject: Re: Powerful macros (was Re: Comparing productivity: LisP against C++ (was Re: Reference Counting))
Message-ID: <D2x4MF.80y@cogsci.ed.ac.uk>
Sender: usenet@cogsci.ed.ac.uk (C News Software)
Nntp-Posting-Host: bute.aiai.ed.ac.uk
Organization: AIAI, University of Edinburgh, Scotland
References: <3fdunb$lr8@news.panix.com> <hbaker-1601952306420001@192.0.2.1> <RFB.95Jan20131054@cfdevx1.lehman.com>
Date: Tue, 24 Jan 1995 16:32:39 GMT
Lines: 38
Xref: glinda.oz.cs.cmu.edu comp.lang.c++:109077 comp.lang.lisp:16477

In article <RFB.95Jan20131054@cfdevx1.lehman.com> rfb@lehman.com (Rick Busdiecker) writes:
>[...]
>I think that there are two issues, power and syntax, which are easy to
>confuse as being a single issue.
>
>I think that the real power of lisp with respect to macros is that the
>programmer is able to manipulate code as data.  You write code which
>takes a parse tree as input and produces a replacement parse tree as
>output, and that code -- your macro definition -- is executed as part
>of the compilation process.
>
>The fact that the syntax of lisp code is identical to the syntax for a
>commonly used lisp data structure (lists) makes it easier to write
>powerful macros, but the ease of use is distinct from the power
>itself.

I think that a key feature is that Lisp macros get something that
is relatively unparsed (that is, it's not already divided up into
expressions) but that also has more structure than strings do.
Macros often parse their arguments, but the parsing is usually 
very easy to do.  The relatively unparsed structure doesn't have
to be lists per se.  Prolog can get similar results using terms.
The Dylan people keep telling us they'll have something far
better, but they won't tell us what it is.

>The fact that the lisp run-time environment usually includes the
>compiler also has interesting implications, however I believe that
>relying on run-time compilation is usually a bad idea.  It has it's
>place, but I think that when you can avoid it, you should.

Common Lisp implementations typically have the compiler as part of
the run-time environment, and the Common Lisp definition defines ways
to call the compiler (the functions compile and compile-file), but
those things are not true of all Lisps.  For instance, Franz Lisp
has the compiler as a spearate program, and Franz Lisp, EuLisp, and
Scheme don't define any way for code to call the compiler.

-- jd
