No macros in Python

[Bruce Hoult]

In article <x7isxtfq1n.fsf at guru.mired.org>, Mike Meyer <mwm at mired.org> 
wrote:

> > |Another prettier way is:
> > |        val = (foo, bar)[pred]
> > |but it evaluates both foo and bar regardless of pred.
> > In other words, this is not semantically a ternary operator.  At least
> > not the one that C programmers are familiar with.  But that spelling
> > does have a certain elegance where the extra evaluation doesn't matter.
> 
> Actually, I became convinced early on in this discussion that Python
> needs two different kinds of macros, because it has two different
> levels of code in it. The "with_output_to_file" is a statement-level
> macro. At the expression level, you could go a long way without adding
> any new syntax to the language.

Right.  In fact due to the conventional syntax, Dylan has *three* 
syntaxes for macro invocation to Common Lisp's one:

 - function macros look like function calls: name( ...args... )

 - statement macros look like existing statements: they start with the 
   name of the macro and end with "end" (then optionally the name of
   the macro)

 - declaration macros look like declarations: they start with "define"
   then some optional adjectives then the name of the macro then the
   name of the thing being defined, and end with "end" (then optionally
   the name of the macro) (then optionally the name of the thing being
   defined).

You can make new syntax using macros, but only in clearly defined and 
limited ways that fit in with the existing syntax.


> I.e., add a "__macro__" function that works similar to the 
> "__staticmethod__" function that wraps a function so that it's now a 
> macro. You'd also have to extend the vm to recognize macro objects as 
> such, because it would have to not evaluate the compiled code objects 
> of the arguments, and tack on the needed extra arguments.

Uhh ... it'd be better to expand them at parse time I expect.

-- Bruce