From: Rick Busdiecker
Subject: Powerful macros (was Re: Comparing productivity: LisP against C++ (was Re: Reference Counting))
Date:
Message-ID: <RFB.95Jan20131054@cfdevx1.lehman.com>
In article <·······················@192.0.2.1> ······@netcom.com (Henry Baker) writes:
In article <··········@news.panix.com>, Viktor Yurkovsky
<········@panix.com> wrote:
> 1, Syntax of the language matters very little.
> ===========================================
Agreed, unless the language is Lisp. In that case, you can use the full
power of macros to write most of the code for you in Lisp. In this case,
the simple syntax matters a lot.
I essentially agree with what I think that you're saying here, however
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.
If C had a real macro system, C++ could be implemented as a set of
macros.
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.
--
Rick Busdiecker <···@lehman.com> Please do not send electronic junk mail!
Lehman Brothers Inc.
3 World Financial Center "The more laws and order are made prominent, the
New York, NY 10285-1100 more thieves and robbers there will be." --Lao Tzu
From: Jeff Dalton
Subject: Re: Powerful macros (was Re: Comparing productivity: LisP against C++ (was Re: Reference Counting))
Date:
Message-ID: <D2x4MF.80y@cogsci.ed.ac.uk>
In article <·················@cfdevx1.lehman.com> ···@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