macro FAQ

[Jacek Generowicz]

jjl at pobox.com (John J. Lee) writes:

> Jacek Generowicz <jacek.generowicz at cern.ch> writes:
> 
> > 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.

I agree. However, my feeling was that the original contained too much
uneducated opinion. I was trying to suggest that we first establish
the facts, and then include opinions based on those facts, rather than
ones based on FUD. Particularly, we should banish the myth that macros
fragment languages, or make code less unedrstandable. (Quite the
reverse is true.)

> [...] the fact that both Guido (I presume?) and most Python users
> don't want macros.

<uk7cpjssf.fsf at boost-consulting.com>

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

The impression I get is that Laura was writing macros for kicks, not
as part of a serious development effort. Of course you could use
macros to write your own language much more easily than if you had to
do it from scratch, but what you would be doing would still be
wrtiting your own, separate, language.

My point is that macros could be immensely useful in making
constructive domain-specific extensions to the language, while _at the
same time_ not fragmenting the Python community.

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

I agree that abstractions usually hide details. I disagree with the
claim that hiding details is the essence of abstraction. To me, the
essence of abstraction is noticing a similarity between certain
"things", understandig how they differ, and encoding the whole set of
them in one implementation, with an obvious degree of freedom which
selects a specific "thing" from the whole family.

If I have a function which is 400 lines long, and I choose to make it
clearer by cutting and pasting bits of its body into smaller
functions, and calling those functions from the original, I haven't
abstracted anything; I have merely split it into more digestible
chunks.

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

But remember that I don't necessarily think they are a good idea in
Python.

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

It might also be the case even in the absence of macros.

Why do so many people here think that macros can perform some
obfuscating magic, of which other language constructs such as
functions or classes are not capable ?

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

It started in the Ruby thread: in Ruby classes are "open".

Say you're developing a class (foo), make a gazillion instances of it,
and play around with them as you are continuing to develop your
program. Suddenly you realize "Darn, I really need a fubar method!"

In Ruby you do something like:

class foo
   def fubar ...

   end
end

All your existing gazillion instances of foo have just acquired a
fubar method, and you can happily continue your exploration with all
the state you built up still intact.

The first thing you might try to do in Python is to add the fubar
method to the class source code, and re-evaluate it ... only to find
that your existing instances know nothing about the new method ... so
you have to go through the hassle of re-creating a gazillion of them,
before you can continue with what you were doing.

(Note, this is advocated as an interactive development aid, _not_ as a
production code technique.)