Macro future proofing

[cmr]

(RFC was accepted and has been heavily amended since; current text is: https://github.com/rust-lang/rfcs/blob/master/text/0550-macro-future-proofing.md )

---

Rendered

Implementation: https://github.com/cmr/rust/tree/macro-input-future-proofing

[cmr]

cc @pczarn @nikomatsakis @kmcallister

[cmr]

Forgot one, of course: =

[nrc]

Could you give some intuition of what the effects are of including or excluding tokens in the FOLLOW sets? I.e., doe sit mean the new token can be used a delimiter token? What does it mean for future proofing? Does it restrict or extend what we can do in the future? How?

I have a feeling we should think about semi-colons, but I'm not sure how. Should they be in the follow sets for either expr or stmt? Is it true that an item must always end with a } or a ;? If so, does that mean we should take anything for FOLLOW for item? (I feel I only have about a 50% grasp of the concepts here, so forgive my possibly stupid questions)

[cmr]

If a token is in the FOLLOW set of a nt, we can never change the language in such a way that parsing that nt would consume that token. This gives us a rigid boundary around which we can change the language and not break macros.

I think the FOLLOW for item could be everything. I think the FOLLOW for meta could be anything, but I'm not sure how that interacts with future plans for letting attributes contain arbitrary token trees. I really don't know about the futures of path/ty. path really ought to be removed, since there isn't really a single "path" that makes sense anymore.

[pczarn]

Consider foo @ pat, an example of $_:pat. We might want to extend the pattern syntax so that pattern guards are allowed in patterns: foo @ pat if condition[1]. Now, let's assume this syntax is going to be added in 1.1. The input foo @ pat if something will continue to be accepted by the matcher ( $bar:pat if something ) for some time, but it will be rejected as soon as 1.1 comes. The culprit is the if in ( $bar:pat if something ) and hence if should be excluded from FOLLOW(pat).

Looks like it's implied that each FOLLOW set contains all identifiers:

If (...) T' is any identifier, continue. Else, reject.

Further, alternation (|) in patterns has been proposed in [1]. I think FOLLOW(pat) shouldn't include Pipe, too.
Edit: in both cases, the syntax that pat parses could be fixed.

[1] RFC: Extend pattern syntax #99, postponed

[cmr]

I'm not sure how we ought to handle identifiers.

[cmr]

For ty I have in the implementation as, ,, ->, :, =, and >. Any token for meta and item. Still not sure about path.

[nrc]

Oh, and a massive +1 to the overall idea here.

[pczarn]

+1, I'm convinced this is necessary. Detailed futures of some NTs are a bit unclear, though.

[cmr]

rust-lang/rust#20563

[nrc]

@cmr are there any changes you'd like to make to this RFC before we merge it?

[cmr]

@nick29581 maybe. The algorithm here no longer reflects the implementation, and the follow sets are subtly incorrect.

[nrc]

@cmr Ok, ping me when you are happy and I'll merge it

[cmr]

@nick29581 this is ready.

[vadimcn]

@cmr, was there a reason for not including Semicolon on this list as well?
It's handy when defining matchers like $( fn $n:ident( $(p:ident : $t:ty),* ) -> $r:ty ; )* (note the trailing 'ty')

[cmr]

No, that was indeed an oversight

sent from my phone
On Jan 23, 2015 12:24 AM, "Vadim Chugunov" notifications@github.com wrote:

In text/0000-macro-future-proofing.md
#550 (comment):

•   continue, else, reject.
  

• 2. If T has the form $(...)U+ or $(...)U* for some token U, run

•   the algorithm on the contents with `F` set to `U`. If it accepts,
  

•   check that the last token in the sequence can be followed by `F`. If
  

•   so, accept. Otherwise, reject.
  

  +This algorithm should be run on every matcher in every macro_rules
  +invocation, with F as EOF. If it rejects a matcher, an error should be
  +emitted and compilation should not complete.
  +
  +The current legal fragment specifiers are: item, block, stmt, pat,
  +expr, ty, ident, path, meta, and tt.
  +
  +- FOLLOW(pat) = {FatArrow, Comma, Eq}
  +- FOLLOW(expr) = {FatArrow, Comma, Semicolon}
  +- FOLLOW(ty) = {Comma, FatArrow, Colon, Eq, Gt, Ident(as)}

@cmr https://github.com/cmr, was there a reason for not including
Semicolon on this list as well?
It's handy when defining matchers like $( fn $n:ident( $(p:ident :
$t:ty),* ) -> $r:ty ; )* (note the trailing 'ty')

—
Reply to this email directly or view it on GitHub
https://github.com/rust-lang/rfcs/pull/550/files#r23432570.