Okay, now that I have a better understanding of the limitations on macros,
I have a couple more questions.
First, the first limitation stated in the tutorial says that the parser is
greedy. However, a lot of the ambiguities referred to in the second
limitation would be eliminated if the parser were greedy in matching
repetitions. As you said, the reason it doesn't do this is to cover up the
internal limitation that attempting match a fragment against a $name:kind
can cause the parser to die, potentially prematurely. However, the
artificially imposed limitation is much stricter than the underlying
limitation, and fails to cover up the underlying limitation completely, at
least right now. For example, the following reports an ambiguity:
macro_rules! map1 (
($($e1:expr $e2:expr a)* $($p:pat $e3:expr b)*) =>
($($e1+$e2)* $(let $p = $e3)*);
)
While the following similar example does not:
macro_rules! map2 (
($e1:expr $e2:expr a) => ($e1 + $e2);
($p:pat $e:expr b) => (let $p = $e);
)
It fails, however, if called as `map2!(_, 3);`, as a result of the internal
limitation, since `_` doesn't parse as an expression. Would it be desirable
for these two examples to have the same behaviour (repetition aside), and
if so, which? Also, how likely is it that the internal limitation (dying on
parse error) could be resolved in the future?
Second, I noticed that once a series of tokens get matched to a $name:kind
instance, they are outputted as a sort of meta-token which will only match
against another $name:kind of the same kind in nested macro invocations and
can't be decomposed. Why don't these meta-tokens get re-tokenized when you
attempt to match them against literal tokens?
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
