Well, I finally ran into a Python Unicode problem, sort of

[Rustom Mody]

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