As an exercise to learn the WikiTalk code i decided to go through and add support for operators. The support is fairly simplistic, due in part to my inexperience with parsers, but I think it's a useful addition and one we can build on.

In this work i added the following things to the parser:

Arithmatic, comparison and boolean operators.

 1 + 2  1 * 2   1 - 2  4 / 2
 4 > 2  4 >= 2  2 < 4  2 <= 4  4 == 4
 true && false  true || false

All the standard ones are there. Operators can be applied to "elements". An element is a literal, a method invocation chain, or a parenthesized expression.

• No support for bitwise operators - i don't personally see this as being very useful for wiki stuff.
• There's no mod (%) operator, but it would be trivial to add.

Operators have their own parse tree node that contains the token for the operator and the left & right hand expressions. They're evaluated in the same way as methods & properties. The ExposedMethod attribute's constructor can take an "operator type" value and will apply that to the corresponding method.

When evaluated the operator parse node evaluates the left-hand parse tree, then invokes the ExposedMethod on the resulting object that maps to the operator type. In this way operators are simply shorthand for instance methods.

This lets the class decide whether it will implement an operator at all, and what the operator will mean. It also allows the class to provide the functionality as a named method. So + can map to String.Append and Integer.Plus depending on the type of the left-hand expression.

Parenthetical expressions

 (5 + 5) / 2

Originally i added these in so one could explictily control precedence where necessary. However i hit some problems getting the C precedence rules to work well in the flexwiki parser (probably my own inexperience here), so they're now a requirement.

I'm actually not upset about them being a requirement though. It saves us from needing to decide on a set of precedence rules, and from arguing about what language they should match.

In my current implementation

 2 + 3 

is valid wikitalk, but

 2 + 3 + 4 

is not - instead you would have to write

 (2 + 3) + 4 

or

 2 + (3 + 4)

It would simplify things even more to require ()'s around any expression that includes an operator .. how do people feel about that?

Comments/Questions

• the whole thing with the () is a joke! we wouldn't have to define rules, someone already did that for us a few 100 years ago!