glebec / functional-math-compiler

Exercise creating a functional JavaScript math expression compiler
MIT License
6 stars 1 forks source link

Complete CST to include parens #6

Open glebec opened 6 years ago

glebec commented 6 years ago

Losing the parens makes the parse tree lose information that could be used e.g. to rebuild the original expression. In other words, we technically have an AST, not a CST. Refactoring to be a CST could work if the Factor tree nodes have lhs, child, and rhs fields as follows:

Production Rule lhs child rhs
F -> (E) Lparen E Rparen
F -> -F Sub F EpsilonF
F -> num EpsilonF num EpsilonF

That way the catamorphism for the recursive generators could look like:

{
  Factor: (lhs, child, rhs) => generate(lhs) * generate(child) * generate(rhs),
  LParen: () => 1, // identity: '' for RPN, '(' for rebuilding original, etc.
  Rparen: () => 1,
}

This is an artifact of the way tree nodes can have varying shape, making it difficult to apply identical logic to every node. An alternative is to simply embrace different node shapes and embed explicit conditional logic in the generator, instead of relying entirely on daggy's cata function for branching.

glebec commented 6 years ago

…another alternative is to consider that there should actually be three separate "factor" node types, one for every arrow in the grammar.

Rule Node Type Children
F -> (E) ExpFactor (, Expression, )
F -> -F NegFactor -, Factor
F -> num NumFactor 3631

This way you can still dispatch based on node type in the generator, without explicit logic. It means the parse tree has a node for every rule rather than one for every symbol.