Python syntax in Lisp and Scheme

[Alex Martelli]

mike420 at ziplip.com wrote:

> Erann - 2, Alex - 0

Daniel P.M. Silva called this "childish and uncalled for" -- but he
says that as if this was news.  To me, seeing childish, uncalled-for
behavior from such adversaries as "mike420" is tiresomely old news.


> Not only did Erann refuse to reciprocate Alex Martelli's ad hominem

He earlier posted my assertions were "mind-boggling", then, without
any apology whatsoever, that he found them reasonable.  So it's not
a matter of E.G. "reciprocating attacks", but, rather, INITIATING
them (and weaving and ducking to admit any responsibility whatsoever).

> attacks, but he made some very good points. Pythonistas! I think
> you need new leaders who will guide you in the right direction.

What next -- claims that I'm hiding weapons of mass destructions,
followed by aerial attacks and land invasion?

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

Actually, "all you NEED is love".  But that, by itself, doesn't
necessarily yield optimal productivity in programming.  What
language design trade-offs WILL yield such optimal productivity,
*DEPENDING* on the populations and tasks involved, is the crux
of this useless and wearisome debate (wearisome and useless, in
good part, because many, all it seems to me on the lisp side,
appear to refuse to admit that there ARE trade-offs and such
dependencies on tasks and populations).

> (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)

The only example of 'power' I've seen (besides the infamous
with-condition-maintained example) are such trifles as debugging-
output macros that may get compiled out when a global flag to
disable debugging is set -- exactly the kind of micro-optimization
that IS typically (and more often than not inappropriately) done
using preprocessors (such as, but not limited to, the C one, see
below).

> 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

...except that I had posted that much earlier, in a deluded attempt
to stop this obviously-doomed thread BEFORE the insults, idiocies
and FUD started flying, of course.  I clearly started out by
saying (emphasis for the benefits of people of scarce reading
comprehension) "you can surely *HACK* a preprocessor on top of
the Python interpreter", defined it as "a toy-level example",
explicitly asserted "I am cutting corners to the bone" (back when
I still could have fun with a little mixed metaphors, ah for the
good old days...:-), and even commented my choice of preprocessors
with a "(!)".  All of these "subtle" hints were, of course, entirely
lost on you: and I'm not particularly hoping for your level of
understanding to have risen in the course of the last 10 days or so.
But I'm recalling them to remind sensible readers (were there to
be any left around) of how utterly, totally, unpardonably absurd
is your implication that your alleged "being the first to come to"
(my) "defense" was something you repented of when you "later realized"
I was me.  The point I was making: integrating preprocessors in the
Python interpreter is easily architected with the new import-hooks
architecture, and I showed how to do it; designing a "good" one "is
left as a trivial exercise for the reader" (I'm sure it was my claim
that I had a perfect one, but the post's margins were too narrow for
me to write it down, that convinced you I was in earnest, right?!).

> #DEFINE and DEFMACRO strikes you, do *not* post any
> of your thoughts and opinions on macros. You just

Many tasks that have been posted as examples in this thread as being
suitable for defmacro, such
as the removal of debugging statements when some flag is set, are
also quite suitable for humbler text->text preprocessors (C's is a
_particularly_ ill-starred one, of course).  

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

Preprocessors and macro processors may do different amounts of, say,
"introspection" on their arguments.  From the point of view of how to
hack a preprocessor in front of the Python interpreter, that matters
zilch.  What DOES matter, of course, is that the language/metalanguage
confusion becomes a bit harder (but far from impossible) to architect into
a preprocessor that's supposed to receive text as input and hand text back
to the following phase[s], rather than working on (e.g.) AST kinds that
are in common with other phases (and s-exprs are such) -- but plugging a
parser in front of a custom preprocessor and a code formatter as its
tail is hardly impossible, if that's how you want your macros to work.

If that IS what you want, in fact, my toy example can reasonably easily
be enriched to e.g. use Python's compiler package to get the ast's, etc;
however, running any kind of separate program / filter is easier, and thus
more appropriate for a toy-sized example -- it matters not a whit whether
the separate program is just cat, doing nothing at all, or cpp, doing just
a little, or that Super-Wonderful Perfect Solution which I have up my
sleeve and this post's too-narrow margins are precluding me from writing
down, _from the point of view of how best to plug such an external phase
into the process of importing Python modules_.


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

I think you're talking through your hat.  I did repeatedly mention
how I suffered the effects of macros' existence and (IMHO) misuse
in my very first job.

> Now that we have educated him about macros, he is probably
> just being stubborn.

Yeah, right.  What, exactly, do you think you've taught me about
macros (as opposed to, about the rudeness of many of their fans)?

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

Remember the context?  Some idiot claiming I'm totally clueless --
is THAT "some kind of technical argument"?  I think, though you
obviously disagree, that I have amply refuted that stupid insult
through the sum total of my posts, both on this and other threads;
pointing out that my books appear to be doing pretty well, and so
does my technical career, just offers other clues as to the utter
and total idiocy of that rant against me.

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

Usenet, in fact, has a glorious tradition of flamewars that
belie your last assertion.  I do agree I would be vastly happier
if this thread was to die the total death it deserved from day
one -- but pointing that out while at the same time making
the kind of inflammatory and insulting remarks that pepper this
post just shows you as spiteful and malignant - or, to put a
very charitable interpretation on it as I pointed out Daniel
did at the top of this response, "childish and uncalled for".

> 
> 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 :-)

<shudder> good thing that Graham's Arc will exist to ensure
common lisp won't thereafter rule unchallenged, eh?


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

We disagree on this.  There are tasks that CAN be handled with
'macros' under both definition (as well of course as many that
only the more powerful kind can handle) -- and along this kind of
_continuum_ you can get many points of currently or formerly
existing and deployed macro systems.  Anything that is run "at
compile time" and generally can produce or alter the input to
following compile-time phases can reasonably be called a macro;
whether the input and output are text, some form of AST, or any
other intermediate language yet, need not, in my opinion, forbid
the use of the term (in an ideal world we might want different
names for vastly distant points in the continuum, but historically
the name macro has in fact often been used throughout it).  Where
we disagree (and of course once we disagree you just _assume_
you're right and I'm wrong, right?) is presumably about the fact
that the set of practical tasks achievable with reasonable ease
by "macros" systems that represent very different overall approaches
along the continuum can and do in fact overlap.  I claim that their
overlap is a fact, as shown by the example where a macro was used
to ensure certain debug-output parts were not compiled at all into
executable code when a global flag meaning "no debug" was set --
an actual example of macro (in the lisp sense) shown on this thread
which is also quite typical of what c-preprocessor macros are often
used for.


Alex