On 10/18/05, Rob Kinyon <[EMAIL PROTECTED]> wrote:
> On 10/18/05, Uri Guttman <[EMAIL PROTECTED]> wrote:
> > my impression is that both styles are supported as you can return either
> > text or an AST (compiled code) from a macro.
>
> That sounds really ... inefficient. For that to work, you'd have to
> have seen the macro definition earlier in the parse cycle,
Of course. Like:
sub foo(&) {...}
In perl 5 where
foo { print "hello" }
only parses correctly if it has seen the definition of the sub before the call.
> then encounter the call to the macro (thus consuming the token),
> unshift the tokens of the macro into the parse queue (thus
> necessitating a parse queue)
Uh, which we have.
> , then reparse the whole block because of potential bracing issues.
No, you wouldn't have to reparse the whole block. You can suspend the
parser while you insert the new text. If you fear lookahead problems
(where we only use lookahead at all in the operator-precedence
sandwitch), you just do macro expansion whenever you shift the
lookahead. That is, you run the macro expander in parallel
(coroutineish parallel, not threadish parallel), and always keep it
one step ahead of the the parser.
> Text-substitution macros would have to be handled in an earlier pass,
I still don't see evidence for this. Or maybe I do, but I don't see
any reason that the preprocessing pass must finish before the parsing
begins.
Luke
