Luke Palmer <[EMAIL PROTECTED]> writes:
> If you define "powerful" as "can do more things," then of course not.
> Lisp is implemented in C, and C's macros are certainly not essential
[aside: most "major" common lisp implementations (cmucl, sbcl,
openmcl, mcl, allegro and lispworks) are all native compilers
implemented in lisp (and some assembler for boot straping). CLISP is
the only "major" implementation whose core is in fact implemented in a
C dialect (for speed reasons (the virtual machine is really slow))]
> But think of what macros in general provide:
>
> * Multi-platform compatability
> * Easier maintenance
* Creating/Embedding custom languages. aka - adapting the
langauge to your problem domain.
common lisp macros allow you to locally extend the vocabulary of
common lisp in the same way engineers have locally (ie within the
engineering domain) extended english with new syntax/semantics to deal
with engineering problems.
macros are functions which are run when the source code is read
(parsed). the argument to a macro is source code (expressed as a data
structure and not simple text) and the return value is source code
(not text). this is a fundamental difference between C's
text-processing macros, without this macros lose most of their power
and become too hard to write to be used.
common lisp's LOOP is a great example of what you can do with macros
(and the best iteration construct around). see
http://www.lispworks.com/reference/HyperSpec/Body/06_a.htm for the
spec and http://www.ai.sri.com/~pkarp/loop.html for a tutorial.
random points and counter-points:
- what macros are really good at is embedding mini-languages and
creating new idioms, this often goes with, but is not nessecarily
related to, reducing lines of code. example: CLOS/MOP (common lisp
object system/meta object protocol) are implemented as macros on top
of non-OO lisp (this statement maybe be a lie if you go deep enough
into the specifics of some implementations).
- the power of lisp's macros is that they allow you to perform
arbitrary code transformations by working with code as if it was
data. at one point there was discussion about having perl subs with
"auto-args" (i forget where i read about this) where by the
arguments to the sub where determined by parsing the body of the sub
itself and looking at what variables where used, this is a trivial
macro in lisp. adding this to perl5 required a source filter which
took forever to write and was never used because is was never
reliable enough (this may say more about my capabilities as a
programmer than about perl5 source filters).
- everything you can do with macros you can do without, since macros
always get expaned (translated) into "regular" common lisp
code. however, sometimes (like with CPS) hand writing the output is
prohibitly difficult.
- some people consider macros to actually reduce maintainability since
they perform arbitrary code manipulations, so you have _no_ idea of
what is going on if you don't know what the macro does. macros which
introduce new symbols are especially vulnerable to this.
- any sufficently powerful tool can be used to shot yourself in the
foot (or blow off your head). i doubt this java-esque argument
(let's "protect" the programmers from themselves) has any weight
with perl programmers, but it's something i've heard more than once.
- writing realiable/robust source filters is hard (do able, but hard,
even with The Damien's Filter::Simple). writing grammars is better,
but still hard, and more importantly, both require a rdically
different mind set from "regular" programming. the ease of writing
lisp macros is largely due to the fact that lisp has no syntax
(almost), and that lisp's syntax is programmable. perl6 will have
the second and can't do much about the first (sort of goes against
"different things should look different").
just another lurker's rant...
--
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
