On Sat, Mar 2, 2013 at 1:41 PM, Paul Stansifer <[email protected]> wrote:
>
> `concat_idents!` is currently broken, and it's my fault. Here's a
> discussion of how it might be fixed in the future:
> https://mail.mozilla.org/pipermail/rust-dev/2013-February/003170.html Sadly,
> there is no workaround. Perhaps it should be removed so that it stops
> confusing people?
>
> Paul
Thanks. So am I to understand that this is a parsing issue -- in
particular concat_idents!(...) doesn't parse like an ident? If so,
since macros already use "$" as special syntax for macro arguments,
and there are only a handful of macro argument types, would it help
for parsing if the macro argument types were made more accessible to
the parser through specialized syntax?
Chosen somewhat arbitrarily, one could use the following prefixes
ident $$
expr $#
ty $^
pat $~
block ${}
so that macro arguments would be declared as $$i, $#j, $^T, etc. Then
the type would be obvious to the parser and all operations between
types could be language-implemented so that the parser understands the
type of the expression it is dealing with.
For example, concat_idents!() could be replaced by ${$$i + _ + $$j},
and the parser could happily accept it as a valid ident instead of
requiring writing two macros when one should suffice. In the end, I
could have something like:
fn ${$$i + _ + $$j} () {
io::println(ident_to_str!(${$$i + _ + $jj}))
}
The other types could similarly be composed: ($~p, ( $~q)) could be a
composite pattern (unless patterns are already allowed to be composed
to create new patterns; not checked). I couldn't come up with useful
compositions of the other types that the parser would choke on.
For example, it is not obvious that ident_to_str!() could be a cause
for problems (for example if a string literal is expected by the
parser). But if it were, $"$$i" or $"${$$i + _ + $$j}" could replace
ident_to_str!($$i) or ident_to_str!(${$$i + _ + $$j}).
Of course, I may be barking up the wrong tree and simply
misunderstanding the underlying problem.
Ashish
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
