[PATCH] D119172: [pseudo] Implement LRGraph

[Alex Tsao via Phabricator via cfe-commits]

alextsao1999 added inline comments.


================
Comment at: clang/include/clang/Tooling/Syntax/Pseudo/LRGraph.h:96
+  uint8_t DotPos = 0;
+  uint8_t RuleLength = 0; // the length of rule body.
+};
----------------
sammccall wrote:
> alextsao1999 wrote:
> > hokein wrote:
> > > alextsao1999 wrote:
> > > > Can we add LookaheadSymbol here to implement LR(1)?
> > > we could do that. However, we don't have a plan to implement an `LR(1)` yet, we use `SLR(1)`. (though LR(1) is more powerful than SLR(1), the typical deterministic LR(1) parser cannot handle the C++ grammar, we need a "general" parser GLR which can be able to handle arbitrary context-free grammars).
> > Thanks for your answering! Oh, I know some `GLR` parsers are based on `LR(1)` or `LALR`, so I think our `GLR` parser is based on `LR(1)` as well. I'm trying to keep up with your train of thought :)
> Yeah, GLR changes the tradeoff between more sophisticated and simpler parsers (LR(1) > LALR > SLR(1) > LR(0)).
> 
> Normally the sophisticated parsers are able to handle grammars/languages that the simple ones can't, by avoiding action conflicts. So the value is very high.
> 
> However with GLR we can handle action conflicts by branching, so the value is "only" avoiding the performance hit of chasing branches that don't go anywhere.
> 
> So it didn't really seem worth the extra implementation complexity (or extra size of the in-memory grammar tables!) to use a more powerful parser than SLR(1). Maybe we should even have given LR(0) more thought :-)
Yes, agree. `SLR` can reduce memory usage, but it can't handle operator precedence. With the help of GLR, we can resolve the problem of operator precedence by chosing one branch. Thanks, I got it!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119172/new/

https://reviews.llvm.org/D119172