macro FAQ

[John J. Lee]

Jacek Generowicz <jacek.generowicz at cern.ch> writes:

> "Andrew Dalke" <adalke at mindspring.com> writes:
> 
> > Here's a proposed Q&A for the FAQ based on a couple recent threads.
> > Appropriate comments appreciated
> 
> Such an FAQ item is probably a good idea.
> 
> However, I think that we should distil out much of the opinion
> (particularly the opinions about opinions of others :-) and try to
> base it on fact:

I disagree.  People reading a FAQ do want to know the opinion of
language users, and more importantly, of Guido, because that's what
explains why the language is as it is, and determines what will happen
in the future.  That's fact too, just fact about people's opinions.


> - what are macros (C-like and Lisp-like),
> 
> - what are the technical difficulties with introducing them into
>   Python

Arguably, these are both secondary issues given the fact that both
Guido (I presume?) and most Python users don't want macros.  Obviously
some background should be in there explaining what macros are and how
they might apply to Python, but Andrew did just that.


[...snip useful technical criticism of Andrew's FAQ...]
> Could you please give me a reference to someone "with plenty of
> experience using macros in Lisp" arguing this ?

Maybe he was referring to Laura Creighton?  He posted a quote and a
link to another of her posts.


[...snip more technical points...]
> But then, functions which provide an abstraction are also more
> difficult to write and understand than ones which merely "move code
> out of the way", and you'd have to think twice whether the abstraction
> is really useful, before deciding to pay the price for writing it, and
> making readers understand it.

I'm amazed that you say this.  I think most programmers would disagree
with you here (certainly I do).  Sure, abstract functions require some
work to understand the concept involved, but the important way in
which one function is easier or harder to understand than another has
to do with how much detail you need to know, not how hard the concepts
are.  Needing to know details causes bugs.  So does needing to know
concepts (though less often), but you can't get rid of the concepts,
whereas you *can* hide the details.  And that's what abstraction is:
hiding details.

(and there's no need to answer here that you think macros are a good
way of hiding detail: we've gathered that ;-)

[...]
> People in the music software "group" will find it hard to use code
> from people writing software for bioinformatics ... with or without
> macros.  This has nothing to do with macros.

But people writing code using one bioinformatics library will not find
it hard to read code using another.  That might not be the case if
macros were built-in.


> OK, I promised some examples of macros. Note that I have not shown a
> single line of Lisp code in these threads, because I agree that it is
> likely to be meaningless to most readers of this group. I'll try
> continue without having to resort to Lisp examples.
> 
> ==== Example 1: a debugging aid ================================
> 
> One litte macro I have for debugging purposes (let's call it "show"),
> allows me to print out the source code of a number of expressions,
> along with their values. At this point, note that Python's horribly
[...]
> The "function" version of the show macro invocation:
> 
>     show(sin(x), a, a + b + c)
[...is equivalent to...]
>     print "sin(x) =>", sin(x)
>     print "a =>", a
>     print "a + b + c =>", a + b + c
[...]
> Can this be implemented using metaclasses, or any other existing
> Python mechanism ?

Yes, using Lisp ;-P -- you can do this in Python with an emacs macro.


> === Example 2: Alexander Schmolck's updating classes ===============
> 
> Alexander recently expressed the desire to have all existing instances
> of a class be updated, when he changes the source of his class, and
> re-evaluates the definition.
[...]

There was a thread recently about how the problem behind this might be
solved in Python.  I started it (a search for "DOM" or "4DOM" or
"hierarchy" and my email address should turn it up).

No, wait a minute -- instances, not classes??  Sounds like an abuse of
the language to me.  What *is* the underlying problem to be solved
here?


John