Python syntax in Lisp and Scheme

[mike420 at ziplip.com]

Erann - 2, Alex - 0

Not only did Erann refuse to reciprocate Alex Martelli's ad hominem
attacks, but he made some very good points. Pythonistas! I think 
you need new leaders who will guide you in the right direction.

Of course, you don't *need* macros, you also do not *need* 
objects, functions, procedures, lambda, modules or floating point
numbers. All you really *need* is IF, GOTO, integers and 
memory.

(This does not change my earlier point that the first examples
of macros in this thread were bad, as they did not show 
The Power)

For the record, I was the first to come to Alex Martelli's 
defense when I thought he was unduly criticised. But later
I realized that he was the same guy who posted that misguided
example of "macros in Python" where he called an external
C preprocessor (CPP). Please, if the similarity between
#DEFINE and DEFMACRO strikes you, do *not* post any
of your thoughts and opinions on macros. You just
do not know what you are talking about. I know he claimed
it to be a "toy" example, but it was not a toy,
it was simply *wrong*. Lisp macros *read* 
and manipulate code passed to them, CPP does not, it's a 
black box to it.

I think Alex Martelli passed judgement on macros without 
knowing anything about them (he admitted that himself
in a post where he talked about his macroless Lisp experience).
Now that we have educated him about macros, he is probably 
just being stubborn.

Actually, I think this discussion was a little too stimulating
for him, so he just lost it, and started making no sense,
claiming to be earning good money writing and consulting 
as if it was some kind of technical argument.

Alex, I still think you are a great guy, and I'm
not being sarcastic, you just need to take a break from it 
all for a while. And remember, USENET is for people who can
exchange ideas without going berserk!

420

P.S. After we add true indentation-based syntax to Lisp, and
auto-translate CPAN into Lisp, all of you Schemers and
Pythonista will be assimilated anyway, so you might as well
give up now and download a verion of CMUCL, or CLISP, if
you run DOS :-)

P.P.S. Alex, I do not blame you for confusing C macros with Lisp
macros. It's not really your fault. It's a terminology problem:
if you know about C macros, and you never had a chance to
learn Lisp macros, it's natural to assume that they are similar.


Erann Gat wrote:

> In article <ue0ib.267972$R32.8718052 at news2.tin.it>, Alex Martelli
> <aleaxit at yahoo.com> wrote:
> 
>> Let's start with that WITH-CONDITION-MAINTAINED example of Gat.  Remember
>> it?  OK, now, since you don't appear to think it was an idiotic example,
>> then SHOW me how it takes the code for the condition it is to maintain
>> and the (obviously very complicated: starting a reactor, operating the
>> reactor, stopping the reactor -- these three primitives in this sequence)
>> program over which it is to maintain it, and how does it modify that code
>> to ensure
>> this purpose.  Surely, given its perfectly general name, that macro does
>> not contain, in itself, any model of the reactor; so it must somehow
>> infer it (guess it?) from the innards of the code it's analyzing and
>> modifying.
> 
> It is not necessary to exhibit a theory of how WITH-CONDITION-MAINTAINED
> actually works to understand that if one had such a theory one can package
> that theory for use more attractively as a macro than as a function.  It
> is not impossible to package up this functionality as a function, but it's
> very awkward.  Control constructs exist in programming languages for a
> reason, despite the fact that none of them are really "necessary".  For
> example, we can dispense with IF statements and replace them with a purely
> functional IF construct that takes closures as arguments.  Or we can do
> things the Java way and create a new Conditional object or some such
> thing.  But it's more convenient to write an IF statement.
> 
> The claim that macros are useful is nothing more and nothing less than the
> claim that the set of useful control constructs is not closed.  You can
> believe that or not.  To me it is self-evidently true, but I don't know
> how to convince someone that it's true who doesn't already believe it.
> It's rather like arguing over whether the Standard Model of Physics covers
> all the useful cases.  There's no way to know until someone stumbles
> across a useful case that the Standard Model doesn't cover.
> 
>> For example, the fact that Gat himself says that if what I want to write
>> are normal applications, macros are not for me: only for those who want
>> to push the boundaries of the possible are they worthwhile.  Do you think
>> THAT is idiotic, or wise?  Please explain either the reason of the
>> drastic disagreements in your camp, or why most of you do keep trying
>> pushing macros (and lisp in general) at those of us who are NOT
>> particularly interested in "living on the edge" and running big risks for
>> their own sake, accordingly to your answer to the preceding question,
>> thanks.
> 
> I can't speak for anyone but myself of course, but IMO nothing worthwhile
> is free of risks.  I also think you overstate the magnitude of the risk.
> You paint nightmare scenarios of people "changing the language"
> willy-nilly in all sorts of divergent ways, but 1) in practice on a large
> project people tend not to do that and 2) Lisp provides mechanisms for
> isolating changes to the language and limiting the scope of their effect.
> So while the possibility exists that someone will change the language in a
> radical way, in practice this is not really a large risk.  The risk of
> memory corruption in C is vastly larger than the risk of "language
> corruption" in Lisp, and most people seem to take that in stride.
> 
>> ...and there's another who has just answered in the EXACTLY opposite
>> way -- that OF COURSE macros can do more than HOF's.  So, collectively
>> speaking, you guys don't even KNOW whether those macros you love so
>> much are really necessary to do other things than non-macro HOFs allow
>> (qualification inserted to try to divert the silly objection, already
>> made by others on your side, that macros _are_ functions), or just pretty
>> things up a little bit.
> 
> But all any high level language does is "pretty things up a bit".  There's
> nothing you can do in any language that can't be done in machine
> language.  "Prettying things up a bit" is the whole point.  Denigrating
> "prettying things up a bit" is like denigrating cars because you can get
> from here to there just as well by walking, and all the car does is "speed
> things up a bit".
> 
> E.