Python syntax in Lisp and Scheme

[Raffael Cavallaro]

gregm at cs.uwa.edu.au wrote in message news:<blr1cq$bb1$1 at enyo.uwa.edu.au>...
> In comp.lang.functional Erann Gat <my-first-name.my-last-name at jpl.nasa.gov> wrote:
> :> I can't see why a LISP programmer would even want to write a macro.
> : That's because you are approaching this with a fundamentally flawed
> : assumption.  Macros are mainly not used to make the syntax prettier
> : (though they can be used for that).  They are mainly used to add features
> : to the language that cannot be added as functions.
> 
> Really? Turing-completeness and all that... I presume you mean "cannot
> so easily be added as functions", but even that would surprise me.
> (Unless you mean cannot be added _to_Lisp_ as functions, because I don't
> know as much as I'd like to about Lisp's capabilities and limitations.)

Two words: code duplication.

Yes, anything that can be done with macros can also be done with
functions, but if you do it with functions, you will end up with more
code, and that code will be duplicated in every single source location
in which that abstraction it utilized.

With a macro, the abstraction is defined once, and the source code
reflects that abstraction everywhere that abstraction is used
throughout your program. For large projects this could be hundreds of
source locations.

Without a macro, you have multiple points of maintenance. If your
abstraction changes, you have to edit scores or hundreds of source
locations. With a macro, you redefine a single form, in one source
location, and recompile the dependent code.

All turing complete languages are computationally equivalent. That
doesn't mean you'll see me programming by punching holes in a paper
tape any time soon though.

Finally, there is one thing that macros can do that ordinary functions
cannot do easily - change the language's rules for functional
evaluation. This can only be accomplished with functions if you're
willing to write a set of functions that defer evaluation, by, say
parsing input, massaging it appropriately, and then passing it to the
compiler. At that point, however, you've just written your own macro
system, and invoked Greenspun's 10th Law.