RE: [Python-Dev] defmacro (was: Anonymous blocks)
Guido writes:
My problem with macros is actually more practical: Python's compiler is too dumb. I am assuming that we want to be able to import macros from other modules, and I am assuming that macros are expanded by the compiler, not at run time; but the compiler doesn't follow imports (that happens at run time) so there's no mechanism to tell the compiler about the new syntax. And macros that don't introduce new syntax don't seem very interesting (compared to what we can do already).
That's good to hear. It expresses fairly clearly what the challenges are in implementing macros for Python, and expressing the challenges makes it easier to attack the problem. My interest comes because some recent syntax changes (generators, generator expressions) have seemed to me like true language changes, but others (decorators, anonymous-blocks) to me just cry out "this would be easy as a macro!". I wrote:
I think it would be useful if we approached it like this: either what we want is the full power of macros (in which case the syntax we choose should be guided by that choice), or we want LESS than the full power of macros. If we want less, then HOW less?
In other words, rather than hearing what we'd like to be able to DO with blocks, I'd like to hear what we want to PROHIBIT DOING with blocks. I think this might be a fruitful way of thinking about the problem which might make it easier to evaluate syntax suggestions. And if the answer is that we want to prohibit nothing, then the right solution is macros.
Guido replied:
I'm personally at a loss understanding your question here. Perhaps you could try answering it for yourself?
You guys just think too fast for me. When I started this email, I replied "Fair enough. One possibility is...". But while I was trying to condense my thoughts down from 1.5 pages to something short and coherent (it takes time to write it short) everything I was thinking became obscelete as both Paul Moore and Jim Jewett did exactly the kind of thinking I was hoping to inspire: Paul:
What I feel is the key concept here is that of "injecting" code into a template form (try...finally, or try..except..else, or whatever) [...] Specifically, cases where functions aren't enough. If I try to characterise precisely what those cases are, all I can come up with is "when the code being injected needs to run in the current scope, not in the scope of a template function". Is that right?
Jim:
Why not just introduce macros? If the answer is "We should, it is just hard to code", then use a good syntax for macros. If the answer is "We don't want xx sss (S\
Or do we really just want a way to say that a function should share its local namespace with it's caller or callee? In that case, maybe the answer is a "lexical" or "same_namespace" keyword.
My own opinion is that we DO want macros. I prefer a language have a few, powerful constructs rather than lots of specialized ones. (Yet I still believe that "doing different things should look different"... which is why I prefer Python to Lisp.) I think that macros could solve a LOT of problems. There are lots of things one might want to replace within macros, from identifiers to punctuation, but I'd be willing to live with just two of them: expressions, and "series-of-statements" (that's almost the same as a block). There are only two places I'd want to be able to USE a macro: where an expression is called for, and where a series-of-statements is called for. In both cases, I'd be happy with a function-call like syntax for including the macro. Well, that's a lot of "wanting"... now I all I need to do is invent a clever syntax that allows these in an elegant fashion while also solving Guido's point about imports (hint: the answer is that it ALL happens at runtime). I'll go think some while you guys zoom past me again. <wink> -- Michael Chermside
participants (1)
-
Michael Chermside