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 <························@news2.tin.it>, Alex Martelli
> <·······@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.
·······@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
In article <························@news1.tin.it>, ·····@aleax.it wrote:
> > Not only did Erann refuse to reciprocate Alex Martelli's ad hominem
>
> He earlier posted my assertions were "mind-boggling"
No, I didn't, as a quick Google search will verify. (Notwithstanding, I
don't consider "mind-boggling" to be a particularly pejorative term.)
> , then, without any apology whatsoever, that he found them reasonable.
I'm pretty sure I didn't do that either, because I don't.
> So it's not
> a matter of E.G. "reciprocating attacks", but, rather, INITIATING
> them (and weaving and ducking to admit any responsibility whatsoever).
Actually it appears to be a matter of you making things up out of whole
cloth (not uncommon on Usenet I'm afraid).
E.
[following up to comp.lang.python and comp.lang.lisp]
Alex Martelli writes:
> 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).
I agree (Lisp side).
> 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
If you are interested in advanced uses of Common Lisp macros, you may
have a look at Paul Graham's book "On Lisp", which is available for
download at his site. Other examples are probably in the Screamer
system by Jeffrey Mark Siskind.
Paolo
--
Paolo Amoroso <·······@mclink.it>