Re: [rust-dev] How to use concat_idents! properly
I'm afraid it's not primarily a parsing issue; it has to do with the Rust implementation, in particular that the same AST type holds pre-expanded code (potentially containing macro invocations) and post-expanded code (in which macro invocations must not be present). Changing the identifier type to be either-an-identifier-or-a-macro-invocation-producing-an-identifier would affect way too much unrelated code. There are a number of ways around the problem, but we need to decide which one to do. Paul ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] How to use concat_idents! properly
In the adding-macros-to-the-AST problem that keeps coming up: Does the 'unrelated' code generally run pre-macroexpansion, or post-? If the answer is 'post-macroexpansion', there may be an argument to be made for splitting the AST types apart? Glenn On Mar 4, 2013, at 9:17 AM, Paul Stansifer wrote: I'm afraid it's not primarily a parsing issue; it has to do with the Rust implementation, in particular that the same AST type holds pre-expanded code (potentially containing macro invocations) and post-expanded code (in which macro invocations must not be present). Changing the identifier type to be either-an-identifier-or-a-macro-invocation-producing-an-identifier would affect way too much unrelated code. There are a number of ways around the problem, but we need to decide which one to do. Paul !DSPAM:5134d6db129152042218820! ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev !DSPAM:5134d6db129152042218820! ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] How to use concat_idents! properly
In the adding-macros-to-the-AST problem that keeps coming up: Does the 'unrelated' code generally run pre-macroexpansion, or post-? If the answer is 'post-macroexpansion', there may be an argument to be made for splitting the AST types apart? It is after macro expansion. However, the two AST types would be really similar to each other; you'd want to generate one from the other using macros. In fact, I attempted to do this the summer before last, but ran out of time. (It wasn't a complete waste: it helped exercise and debug the macro system.) It *might* be more practical to do it now that the macro system has improved, but it's still no small project, and I wouldn't blame anyone for vetoing making such a large change to the Rust AST out of a generally precautionary attitude. Paul Glenn On Mar 4, 2013, at 9:17 AM, Paul Stansifer wrote: I'm afraid it's not primarily a parsing issue; it has to do with the Rust implementation, in particular that the same AST type holds pre-expanded code (potentially containing macro invocations) and post-expanded code (in which macro invocations must not be present). Changing the identifier type to be either-an-identifier-or-a-macro-invocation-producing-an-identifier would affect way too much unrelated code. There are a number of ways around the problem, but we need to decide which one to do. Paul !DSPAM:5134d6db129152042218820! ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev !DSPAM:5134d6db129152042218820! ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] How to use concat_idents! properly
So far, I have had a difficult time finding anything definitive on this
except for some rust test code.
fn main() {
// PART 1: works (from rust test code)
let asdf_fdsa = ~.;
io::println(concat_idents!(asd, f_f, dsa));
io::println(stringify!(use_mention_distinction));
// PART 2: creating a function identifier
fn concat_idents!(foo, _, bar) () { // fails to compile
io::println(Foo!);
}
foo_bar();
// PART 3: a numeric is a bad identifier, but a good sub-identifier
let asdf3 = ~.;
io::println(concat_idents!(asdf, 3)); // fails to compile
}
The first part works fine.
The second part, creating a function identifier seems a perfectly valid
use-case, but fails compilation, and I don't know a valid work-around. I
have been unable to find a similar usage anywhere.
This third part was just some wishful thinking, actually, but if there are
ways to do this directly (other than changing 3 to a valid identifier
like N3), I would love to know.
(Though, this might not longer have much of a use case if/when generics
eventually support integral parameters.)
Ashish
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] How to use concat_idents! properly
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.
Ashish
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
