It seems that we need unary operators to participate in order to also add ** to the set of operators...

@pablogsal How do you feel about this? Should we finish it up (fix the merge conflict) and land it, or abandon?

@pablogsal How do you feel about this?

I am torn: I really like the speedup but I dislike that some operators have their precedence defined via the new method and some others (unary and **) use the "regular" method. It makes a bit complex to document the grammar as it uses two different methods for the same purpose.

Regarding the code complexity, I think is fine as is very localized and although the algorithm can be a bit more complex because the common stack, I think is readable and small enough to not be a major problem IMHO.

I think that unless we found a straightforward way to include unary operators (so we can also include the right-associative **), I propose to abandon this to not increase the complexity of documenting the grammar (and the grammar itself).

What do you think?

Agreed. We could shelve it now and consider it if we get demands for a faster parser.