do...until wisdom needed...

[Alex Martelli]

"Douglas Alan" <nessus at mit.edu> wrote in message
news:lc3dagojmw.fsf at gaffa.mit.edu...
    [snip]
> Debugging can be an issue.  Broken macros can be hard to debug.  A

True, and very important, but perhaps not a show-stopper if the
need that is filled by macros is as crucial as you claim.  Templates
(which you might see as a "special case" of macros, without the
"flexibility in syntax sugar" part!) DID catch on in a BIG way in C++,
despite the HORRID quality of diagnostics typically emitted by
compilers when a template is misused, because they DID satisfy
a truly huge need -- code reuse by signature-based polymorphism
(albeit compile-time only).

> person who implements a macro should test his code well.  Support for

Necessary but not sufficient, just like testing code well before
making it a template in C++.  The problem is not only with a
defective template (or macro), which is pretty bad already, but
with defective USE of it in client-code -- the diagnostics for
that _misuse_ are generally whacky indeed in my experience (I
don't know if some C++ compilers today give GOOD diagnostics on
template misuse -- I've never met any).  Still, as I said, not
necessarily a show-stopper _IF_ Python programmers in general
should find the extra capabilities of the macro mechanisms as
indispensable as C++ programmers have come to find the kind of
things templates give them.

> macros in other tools is no more difficult than for features such as
> OO and functions, but requires some amount of effort to do correctly.

Python's syntax-sugar is currently fixed.  Most tools parse it
pretty superficially -- recognizing a few keywords and patterns
is enough.  If macros allow syntax-sugar to change more or less
at will (as it seems to me you've claimed they could), then the
task of parsing *WILL* become more difficult than with fixed
syntax sugar -- I find your claim to the contrary surprising.

One can't rely on EVERY tool accessing some hypothetical Python
provided component for parsing, of course -- each tool has its
own architecture, and one can hardly expect to rearchitect many
dozens of editors, for example, that are in common use for Python
today and get by with "superficial parsing".

The issue is not as large in Lisp for macros that keep the
usual, crystal-simple Lisp syntax sugar, of course -- just
sequences of whitespace-separated atoms and lists within
parentheses; that can still be superficially-parsed without
too much trouble.  But the few examples of hypothetical
Python macros I've seen you offer do appear to touch Python's
surface syntax sugar quite a bit more -- one of your first
desiderata, the "let x" and "set x" macros to allow variable
declarations, being just one simple example.  Therefore, it
appears to me that supporting the macros you dream of in
other tools, such as umpteen editors, _IS_ indeed going
to be more difficult than supporting constructs that, whatever
their semantics, do *NOT* affect syntax sugar in the least.


> > Proving otherwise then becomes that much more complicated, which
> > explains at least some of the resistance you've seen from me and
> > others.
>
> The proof of the pudding is in it's eating.  I've eaten from the macro
> pudding and therein I found all the proof I need.

You've found macros very useful in Lisp.  That may be all the
proof YOU need that you can design a macro system for Python that
Pythonistas will find just as useful, indeed so useful as to
overcome the issues with diagnostics and tools-support, but
apparently some of us consider this a rather large "leap" and
would much rather see some sort of strawman pre-PEP at least.

We agree that the proof of the pudding is in the eating.  But
from the fact that I particularly enjoy a certain kind of chutney
on a steak and kidney pudding, I'm not going to infer it will
be as enjoyable on a chocolate rice pudding... it would
seem rather a large "leap" to me.


Alex