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

Layout processor should use token IDs, not their String rendering #352

2 of 4 tasks
andreasabel opened this issue Apr 7, 2021 · 1 comment
2 of 4 tasks
enhancement layout Concerning layout (keywords)


Copy link

andreasabel commented Apr 7, 2021

The current layout preprocessor renders tokens as String to check whether they match layout keywords or { } ;. However, each keyword/symbol token comes with an ID that could be checked faster.

Steps to rewrite layout processor (generator) to use IDs instead of String:

  • LBNF: check whether { } ; occur in grammar when layout is used.
  • Give each symbol a name, like ( is LPAREN.
  • Define token constants in generated lexer for all the keywords and symbols.
  • Reference these constants in the layouter, rather than strings.
@andreasabel andreasabel added enhancement layout Concerning layout (keywords) labels Apr 7, 2021
@andreasabel andreasabel self-assigned this Apr 8, 2021
@andreasabel andreasabel added this to the 2.9.2 milestone Apr 8, 2021
andreasabel added a commit that referenced this issue Apr 9, 2021
Instead of _SYMB_nnn, we have _LPAREN, _KW_while, and T_Identifier.
Copy link
Member Author

I chose a different implementation path: Simply use TokSymbol (with the token ID) instead of String in the generated Layout.hs. We need not define constants for each token ID in the lexer. Could be still nice, but this is another issue.

andreasabel added a commit that referenced this issue Apr 19, 2021
Braces are not needed for toplevel layout, so we should not require them.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
enhancement layout Concerning layout (keywords)
None yet

No branches or pull requests

1 participant