On Sat, Mar 2, 2013 at 2:20 PM, Ashish Myles <marci...@gmail.com> wrote:
> On Sat, Mar 2, 2013 at 1:41 PM, Paul Stansifer <paul.stansi...@gmail.com>
> 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.
>
To allow writing general macros that return identifiers (as opposed to
generating code), they could optionally be prefixed by the type they
return, such as
$$concat_idents!($i, _, $j)
(They would also have to be defined like so.) This is, of course,
going down the scary perl route to deal with parsing issues.
And it might be inching closer to constexpr-like behavior.
Ashish
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
