> Larry Wall wrote: > [snip] > > Nope. $x and $p are syntax trees. > > <blink> > > Macros are passed syntax trees as arguments, but return coderefs? > > That's... odd. > > I would expect that a macro would be expected to *return* a syntax > tree... which could then undergo (more) macro-expansion.
Keep in mind, a macro can return a lot of things to get a lot of different behavior. It can return a string which will be inserted in the input stream in place of the macro call; it can return a closure which will be inserted into the generated code at that point. Along the same lines, you can return a syntax tree to be inserted into the, um, syntax tree at that point. Perhaps with C<template>, as Larry mentioned earlier (though I'm not sure that he intended this meaning): template { $x + 1 } Would return a syntax tree for $x + 1. Obviously, the syntax tree would have to be closure-like, because the string '$x' isn't enough to represent this $x. It would have to keep some sort of reference to the lexical... or lexical table entry... or something. And indeed, that would solve the macro recursion bit, if the just-inserted syntax tree underwent more macro expansion. Luke > Sortof like how in lisp, a macro recieves lists as arguments (those > lists being un-evaluated code) and then returns a list, which then has > more macro expansion done on it, and then gets parsed and evaluated. > > -- > $a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca > );{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "[EMAIL PROTECTED] > ]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}