The flattening procedure in the paper proposes a right recursive definition of the star operator (a* -> B -> a B | ε).
However, left recursive definitions (i.e., B -> B a | ε) are known to have reduced stack activity when it comes to LR-style parsers and should lead to more performant parsers.
The CPS transformation step appears to rely on the right recursive definition. (Construction 3.3, third case, first subcase)
I feel like, the CPS approach combined with the approach found in https://github.com/jzimmerman/langcc/issues/44 could allow for a left recursive definition. Data could be stored during the flattening procedure, which could be used to guide the CPS-transformation.
The flattening procedure in the paper proposes a right recursive definition of the star operator (
a*
->B -> a B | ε
).However, left recursive definitions (i.e.,
B -> B a | ε
) are known to have reduced stack activity when it comes to LR-style parsers and should lead to more performant parsers.The CPS transformation step appears to rely on the right recursive definition. (Construction 3.3, third case, first subcase)
I feel like, the CPS approach combined with the approach found in https://github.com/jzimmerman/langcc/issues/44 could allow for a left recursive definition. Data could be stored during the flattening procedure, which could be used to guide the CPS-transformation.