If not, then the expression doesn't seem to be ambiguous, but I can see,
that writing the parser would be more tedious.
So is this the reason, an easier parser implementation and therefore
most likely faster parsing of code?
It's not so much the speed of the parser that is the matter, but
(note that you should wrap your second RHS in `{}` in order to avoid
hitting the following bugs: https://github.com/mozilla/rust/issues/8012
https://github.com/mozilla/rust/issues/4375)
I had misunderstood your original question: now I see that, by operate
on, you meant that you wanted to run the
Originally I *did* want to operate on AST, because I couldn't get macro
system to parse more than the first statement when I was writing my rules
like this:
( $head:stmt ; $($rest:*stmt*);+ ) = ( $head ; stmt_list!(
$($rest);+ ) );
Apparently interpolated statements cannot be re-parsed
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
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
#2 had never occurred to me. I think I lean toward it, since it has the
potential to be a simpler implementation. (And you could even use it to
clean up the crufty can't-happen errors that I introduced when I made fold
able to fold into zero items.)
Paul
Rust syntax expects a literal number in the `[T * n]` construct; from the
parser's point of view, what it receives is an expression, without any
information that it is a number. (There are internal reasons for this, but
it also makes the behavior of `$` more consistent; for example, preventing
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
Alternation already exists, at least at the outer level:
macro_rules! alt_example(
( cons($e1:expr, $e2:expr) ) = ( ... )
( mt() ) = ( ... )
)
Of course, making use of it for something other than a whole macro
invocation requires the use of a helper macro, which can be tricky if the
It's just a matter of not having implemented it yet. Each new macro
invocation location unfortunately requires modifying the AST, which affects
all the code that is interested in that part of the AST. It's not a huge
amount of work, but it does inflict lots of can't happen error cases on
unrelated
Your analysis is solid; those are the main options, as far as I can tell.
TL;DR: Advantages and disadvantages! Implementation concerns! Smurfs! Third
option somewhat preferred by me!
- I agree that macros-in-identifier-position is appealing linguistically,
but it's a bit tricky for internal
The code in the Rust repo *is* the code for the snapshot compiler.
Since the Rust compiler is written in Rust, everyone has to download a
binary version of the compiler in order to compile their own copy.
In the distant past, there existed an Ocaml compiler for Rust, which
was how the process was
Patrick proposed a new syntax for macro invocations. Summary from
https://github.com/graydon/rust/wiki/Syntax-extension:
Expr → # Path BalancedLexemes
BalancedLexemes → ( BalancedLexemes * )
BalancedLexemes → [ BalancedLexemes * ]
BalancedLexemes → { BalancedLexemes * }
BalancedLexemes →
Thanks!
#macro(zip_or_unzip) alt {
case ([[x, ...], [y, ...]]) { [[x, y], ...]] }
case ([[xx, yy], ...]) { [[xx, ...], [yy, ...]] }
}
I know, it's more verbose, but (a) it doesn't repeat itself, (b) it re-uses
an existing construct rather than create a new one.
I think I
14 matches
Mail list logo
