Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Basic proc-macro identifier vs keyword disambiguation. #141

Open
eddyb opened this issue Mar 21, 2020 · 1 comment
Open

Basic proc-macro identifier vs keyword disambiguation. #141

eddyb opened this issue Mar 21, 2020 · 1 comment

Comments

@eddyb
Copy link
Member

eddyb commented Mar 21, 2020

If the built-in proc-macro IDENT rule is computed after regular rules are added, it could depend on a user-defined rule, let's say KEYWORD, such that:

KEYWORD = "be" | "in" | "lambda" | "let";

would result in IDENT matching any proc-macro identifier except let and lambda.

That would make this grammar less ambiguous (e.g. for (lambda x x) y or let x be y in (x x)):

Expr
    = Var:IDENT
    | Paren:{"(" inner:Expr ")"}
    | Lambda:{"lambda" var:IDENT body:Expr}
    | LetIn:{"let" var:IDENT "be" init:Expr "in" body:Expr}
    | Call:{callee:Expr arg:Expr}
    ;

To recover the old behavior, one could add a IdentOrKw = IDENT | KEYWORD; rule.

While implementing this efficiently would be difficult at this time, proc-macro support isn't exactly fast either, as it has to work with a limited API.

@eddyb
Copy link
Member Author

eddyb commented Mar 28, 2020

One way to prototype this would be to add an argument to the proc_macro::builtin grammar, and have it generate the requisite rules - including an IDENT_OR_KEYWORD with the same (cheap) implementation as today.

EDIT: in the interest of testing, I should just do the full thing, and I can still expose IDENT_OR_KEYWORD.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant