On Wednesday, 20 February 2013, Paul Stansifer wrote: > > Any idea why? () could be considered an expression, but it's not in an >> expression position, and a lot of things could be considered expressions >> and don't do this. >> > The local ambiguity errors exist for the internal reason that the Rust > parser `fail`s (I guess now it `die!`s) when it gets a parse error. > Therefore, the macro system refuses to start parsing a nonterminal (in this > case, expr), unless it can conclusively rule out all other options (in this > case, I think, the token ")", which occurs if there are 0 exprs in that > sequence), using one character of lookahead. And it isn't aware what > nonterminals can and can't start with, so the fact that ")" isn't the > beginning of an expression isn't useful to it (hm. It'd be a bit of a hack, > since we'd need to manually generate a table of acceptable start tokens, > but maybe adding that feature would make macro writing easier.). The > general solution is to make sure that the first thing inside a `$(...)*` > isn't a `$name:nt`. I think the macro tutorial (or possible the reference > guide) may have more information. > > Paul > > The tutorial example of ambiguity was so straightforward that I was lulled into complacency ;). I was misled by the apparent special treatment of delimiters, which is actually the result of the rust parser and not macro expansion*. Further complicating things is that identifiers, alone among non-terminals, can be matched against terminal symbols, which lets me do things with them that I can't do with patterns and expressions, which I didn't realize at first.
* The delimiters have to be balanced so that the rust parser can find the outermost ones delimiting the input to the macro. The outermost delimiters behave differently from the nested ones since they don't actually form part of the input to the macro.
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
