On Monday, July 4, 2016 at 3:56:43 PM UTC+5:30, BartC wrote: > On 04/07/2016 02:15, Lawrence D’Oliveiro wrote: > > On Monday, July 4, 2016 at 12:40:14 PM UTC+12, BartC wrote: > >> The structure of such a parser doesn't need to exactly match the grammar > >> with a dedicated block of code for each operator precedence. It can be > >> table-driven so that an operator precedence value is just an attribute. > > > > Of course. But that’s not a recursive-descent parser any more. > > > > All the parsers I write work the same way. If I can't describe them as > recursive descent, then I don't know what they are. > > This is just recognising that a bunch of specialised functions that are > very similar can be reduced to one or two more generalised ones.
In gofer (likewise Haskell) one can concoct any operator and give it a precedence and associativity -- l,r,non Internals of Haskell I do not know, but of gofer I can say the following: Implementation is in C. Uses yacc to parse all operators left-assoc, same precedence Then post-processes the tree with an elegant little shift-reduce parser based on specified precedences and associativities. I sometimes teach this to my kids as an example of how FP-style comments can clarify arcane imperative code: Mark Jones (gofer author) original version + My version made executable http://blog.languager.org/2016/07/a-little-functional-parser.html -- https://mail.python.org/mailman/listinfo/python-list
