- 
                Notifications
    You must be signed in to change notification settings 
- Fork 10
WIP: SLR parse table generation #27
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
base: develop/jsglr2
Are you sure you want to change the base?
Conversation
| Great stuff! | 
3f93359    to
    a1809ec      
    Compare
  
    6f513b7    to
    e68c54c      
    Compare
  
    e68c54c    to
    961359f      
    Compare
  
    961359f    to
    ddc6784      
    Compare
  
    **The Problem:** In `NormGrammarReader.processSymbol`, a cache is maintained for symbols that are already processed. However, this cache did not take into account that Symbols with and without a Label should be treated as equal (e.g. `tail:Stm` and `Stm`, see org.spoofax.jsglr2.integration/src/main/resources/grammars/layout-sensitive.sdf3). These labels are only used to reference the symbols from the layout constraints, but do not actually contribute to the meaning of a production. **Why is this a problem?** For SLR parse table generation (see metaborg#27), all grammar symbols are assumed to be unique. However, because Symbols with or without a Label were not treated as equal, the "graph" used to calculate the First- and Follow-sets became disconnected. This in turn caused some symbols to have empty First-/Follow-sets. The productions belonging to these symbols would not get any reduce actions in the parse table, because if the Follow-set is empty, no lookahead is allowed. **Current solution:** When processing symbols in the `NormGrammarReader`, any Label constructor is removed from the symbol term. **Discussion:** I have tried looking around where these labels are used (I am assuming layout constraints, but I couldn't find how they are processed in NormGrammarReader). Depending on their usage, it might be a good idea to apply this filter in Stratego already, e.g. in the strategy `module-to-normal-form`. @udesou any feedback is appreciated, as always 🙂
ddc6784    to
    9fa417d      
    Compare
  
    9fa417d    to
    f2d4c12      
    Compare
  
    7d49367    to
    582dcc1      
    Compare
  
    f9083b1    to
    084742e      
    Compare
  
    This EOFSymbol was introduced when changing the EOF value from 256 to -1
@udesou Just to get some feedback, and also to check whether this will not conflict with your upcoming refactorings.
I've implemented SLR parse table generation in
sdf2tablebased on http://compilers.iecc.com/comparch/article/01-04-079, as was linked in theFIXMEcomment. Some remarks:symbolProductionsMappingof the grammar.The refactoring of character classes of Refactor CharacterClass: use ICharacterClass where possible #26 is not used yet, as experimenting with SLR parse table generation was my inspiration for this refactoring. (EDIT: done!)Thanks in advance for your feedback! 🙂