Every so often I create some sort of little language, of lesser or greater power, and when I do I have some heresies (like using recursive descent parsing ). One of those heresies is that I usually leave out real operator precedence, other than support for '(' and ')'.

Operator precedence is nice and there are all sorts of cool algorithms for implementing it without tearing your hair out. But it's mostly nice for arithmetic expressions (or if you have a lot of operators), not for other things you may be using expressions for, such as matching incoming connections against some rules , and implementing real operator precedence will complicate your parser and little language. If you do this regularly and have the relevant algorithms memorized, or if you want an extra learning experience, go ahead and implement operator precedence anyway. Otherwise, well, are you sure you need it? I've been pretty happy with little languages that had little or no operator precedence, among other hacks to make them simpler.

(A certain amount of basic operator precedence can be implemented fairly simply in a recursive descent parser, although it can be increasingly tedious as you add more and more levels.)

The question of whether you need operator precedence is partly one of language design and partly one of how your little language is going to be used in practice. If you have multiple operators and people are going to intermix them, writing out some sample pieces of your little language may rapidly show you that you need operator precedence. Alternately, you may find yourself struggling to find a situation where it's natural to write an expression that requires operator precedence, or at least that requires sophisticated algorithms for it.

Another thing that makes operator precedence easier in little languages is not having very many operators (this especially the case in recursive descent parsers). The cool algorithms for operator precedence mostly come up if you want to have a lot of operators with a lot of precedence levels; if you're happy to just have a couple of operators, life is rather easier.

(Now that I've looked at parts of my past work, there's a little bit more operator precedence in some of it than I was expecting, although it's all done with basic recursive descent parsing.)

PS: Another thing that happens with operators in the kind of little languages that I wind up creating is that the operators are things like 'and', 'or', 'except', or set intersection and difference, where the precedence I should assign to them isn't particularly obvious. Once again, writing out sample expressions, rules, and so on can clarify how you're likely to want to use your thing in practice.