Python syntax in Lisp and Scheme

[Marco Antoniotti]

Alex Martelli wrote:

> Kenny Tilton wrote:
> 
....
> 
> The very 'feature' that was touted by Erann Gat as macros' killer advantage
> in the WITH-CONDITION-MAINTAINED example he posted is the crucial
> difference: functions (HO or not) and classes only group some existing code
> and data; macros can generate new code based on examining, and presumably to
> some level *understanding*, a LOT of very deep things about the code 
> arguments they're given.  If all you do with your macros is what you could
> do with HOF's, it's silly to have macros in addition to HOF's -- just 
> MTOWTDItis encouraging multiple different approaches to solve any given 
> problem -- this, of course, in turn breeds divergence when compared to a
> situation in which just one approach is encouraged.  If you do use the 
> potential implied in that example from Gat, to do things that functions and 
> classes just couldn't _begin_ to, it's worse -- then you're really 
> designing your own private divergent language (which most posters from
> the Lisp camp appear to assert is an unalloyed good, although admittedly
> far from all).  This is far from the first time I'm explaining this, btw.

I am extremely careful to design new macros for my "extensions".  And 
when I do so I do it in my specialized packages.  Moreover, I am 
personally against blindly importing names when you do not actually need to.

This may or may not cause language divergence.  It is a social issue 
that is rather independent.  For example, people forget Greenspun's 
Tenth Rule of programming every other day and continue to diverge :)


> 
> Oh, and if you're one of those who disapprove of Gat's example feel free
> to say so, but until I hear a substantial majority denouncing it as idiotic 
> (and I haven't seen anywhere near this intensity of disapproval for it from 
> your camp) I'm quite justifyied in taking it as THE canonical example of a 
> macro doing something that is clearly outside the purview of normal tools 
> such as functions and classes.  As I recall there was a lot of that going
> on in TI labs, too -- instead of writing and using compilers for hardware
> description languages, circuit simulators, etc, based on appropriate and
> specialized languages processed with the help general-purpose ones,
> the specialized languages (divergent and half-baked) were embedded in
> programs coded in the general-purpose languages (Lisp variants, including 
> Scheme; that was in 1980) using macros that were supposed to do
> everything but serve you coffee while you were waiting -- of course when
> the snippets you passed (to represent hardware operation) were correct
> from the GP language viewpoint but outside the limited parts thereof that
> the macros could in fact process significantly down to circuit design &c,
> the error messages you got (if you were lucky enough to get error
> messages rather than just weird behavior) were QUITE interesting.

What people were doing not too long ago (1998) in a major electronic CAD 
company was to develop special intermediate languages to represent some 
design modules (we are talking about a not-so-cheap application here). 
Guess what.  They were using a tabbed format.  Going from version 1.0 of 
the product to version 2.0 involved writing a complex "migration" tool, 
as the previous format would break (not to mention the common place "cut 
and paste" errors).

How would you do that today?  You would write a XML DTD (or Schema, if 
you are so inclined) to achieve the same goal.  Now, given that XML is 
S-expr in a drag, Greenspun's Tenth applies again.

This has nothing to do with HOF vs Macros etc etc, but it shows that you 
are always using some "language design" thingy while you program.  After 
all, Stroustroup correctly said that "library design" is "language 
design".  Jumping back to the topic, the bottom line is that you want 
both macros and HOFs.  If you do not want both you are just reconfirming 
Greenspun's Tenth Rule of Programming :)


> 
>>One popular macro is WITH-OUTPUT-TO-FILE. My budding RoboCup starter kit
>>was a vital WITH-STD-ATTEMPT macro. Oh god, no! I need to see the ANSI
> 
> 
> Do they do things a HOF or class could do?  If so why bother using such
> an over-powered tool as macros instead of HOFs or classes?  If not, how do
> they specially process and understand code snippets they're passed?

Because you have them and because they are easier to use than a HOF.  If 
you have both you can make the best of both.  If you miss either, you 
have one less tool in your belt.  As for the previous examples, you do 
not necessarily need to understand the code snippets that are passed to 
the macros.  Most of the time macros are used as code transformations. 
If you use them carefully, then your (Common Lisp) programs get more 
succinct and more readable (and, incidentally more efficient, as Common 
Lisp can use macros to shortcut the road to the *NATIVE CODE* compiler). 
You cannot achieve this effect if you do not have both.

Cheers
--
marco