What can you do in LISP that you can't do in Python

[Cameron Laird]

In article <mailman.989861961.6105.python-list at python.org>,
Steven D. Majewski <sdm7g at Virginia.EDU> wrote:
>
>
>I was about to bring up Turing Completeness, but Alex beat me to it!
>
>But for an example to consider: 
>
> Pretend for a moment that you had a problem where you absolutely 
>required something like Lisp macros.
>
> In python, you could always the the equivalent behaviour with a 
>python function that outputs a new python module that could be
>imported. Programs that write programs isn't a feature that only
>Lisp can do. 
>
> However, because of Lisp's trivial syntax, as well as functions
>designed for reading lisp expressions, processing Lisp code is 
>trivially easy. Lisp macros are written in a sort of substitution
>template. 
>
> Doing the same thing in Python requires a Python parser. Of course,
>you just happed to have access to the one built into Python from 
>the parser module. ( "import parser" ) 
> However, other than occasionally  eval-ing small expressions, I 
>think most Python programmers would, rather than write some sort
>of textual code processing, would use the reflective features of
>the language manipulate classes, functions, code-objects, et.al. 
>at a different level. 
>
> I haven't followed Dylan for a while (Dylan is a language that's
>sort of like an Object-oriented Scheme in it's semantics, but with
>a more "algolish" syntax ) but, long ago, there was discussion of
>a macro system for Dylan, which was planned to be a non-textual
>transformation of deeper structures from the parse tree. 
>
> If you were going to do macros for Python, that would be the way
>to do it -- however, I wonder if that style of macro would ever 
>feel as natural as Lisp's.  I suspect that Python programmers would
>STILL try to find another way to do it. 
>
> There's a lot more to a computer language that a list of features!
			.
			.
			.
I have a pet belief that hygienic macros as practiced
in Lisp are somewhat overdone (I know my own fondness
for extreme factorization), and of material interest
largely for a single category of use:  "self-modifying"
code which amounts to initialized method definition.
Exactly the same calculations are available in a purely
run-time formulation, withOUT macro funniness, but at
the cost of more run-time calculation.

Until I have more evidence to the contrary, I expect
correct macro usage to be a performance optimization.

Python admits fine, powerful metaprogrammability.  It
needn't apologize.
-- 

Cameron Laird <claird at NeoSoft.com>
Business:  http://www.Phaseit.net
Personal:  http://starbase.neosoft.com/~claird/home.html