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

[Steven D. Majewski]

On 14 May 2001, Cameron Laird wrote:

> 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.

I don't think they are overdone. 
They *really* are major, general features of the language, Cameron. 

Think of it this way: 

 There are forms that evaluate all of their arguments and
 there are forms that don't evaluate all of their arguments. 

 The first bunch are called function and you can define your own. 

 The second bunch are called "special forms" and include things 
 like IF, WHILE, SETQ and WITH-OPEN-FILE, and you can also define
 your own using what are called Macros. 

 ( Smalltalk, instead of having these different forms, has a way
   of slinging around unevaluated code blocks as parameters:

    object ifTrue: [ block of code to be evaluated ]
	   ifFalse: [ block of code to be evaluated ] 

  i.e. the conditionals aren't control structures like in most 
   languages, but are regular methods -- it's the arguments --
   the unevaluated code blocks -- that are different.
   As usual, Lisp and Smalltalk come up with solutions that are
   at right angles to each other! ) 
 
  Thinking of Macros as programs-writing-programs is not the main
  point -- the main point is the control of when things are evaluated. 
  ( Isn't this a feature of Tcl, also ? ) 

  Macro's are also used for some of the sort of stuff the C-preprocessor
  is used for. That could be optimization, although in Common Lisp as in
  C, an inline compiler directive is the preferred way. More often, 
  just as in C, it can be used to hide details or avoid a lot of 
  repetitive typing. ( I've used it, for example, to avoid having to
  type a bunch of nearly identical accessor methods for each field 
  of a data structure. ) 
  
  And, it's probably only in AI or compilers that you get
  programs-writing-programs-in-the-large. 
 

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

 I agree. That was part of my point: that Python programmers would choose
 to do it differently, and use other metaprogramming and introspection
 features. ( And that even if you grafted Macro's onto Python -- as was
 discussed in another thread -- they wouldn't fill the role they do in 
 Lisp -- that you can't just add features from one language to another
 and expect to get something that works the same! ) 

 Now -- if you want to know my biggest gripe about Lisp: it's that 
 it doesn't have array or sequence access that's quite as handy as 
 'a[i]'   It wouldn't be that hard to add it with a little readtable
  programming and a macro or two, but then it would look SO out of 
  place in Lisp code -- like one of those bolted-on features! 

-- Steve Majewski