Trying out a useless operator

[qwertie]

Submitting issues is easier than writing blog posts, so here we are. I am kind of hoping that discussing how to add features might be useful to people who might want to hack on this someday.

A long time ago I defined a funny prefix operator in LES, called simply |. It has lower precedence than any other operator, and I figured it might come in handy for code that looks like Nemerle:

// Nemerle example adapted to LESv3 syntax
.match object {
  | pattern1 |> doSomething
  | pattern2 when condition |> doSomethingElse
  | pattern3a
  | pattern3b |> doAnotherThing
  | _ |> doSomeOtherThing
}

[Edit: this operator will morph to a new form - see #86]

This operator has a "precedence override effect": any time it appears in an expression, it gobbles up everything to its right, regardless of what operators appear on the left. For example,

x * | a && b = c

is parsed as x * (| (a && (b = c))) despite the high precedence of *. (Note: this example highlights another quirk of LES; a && b = c && d is parsed as a && (b = (c && d)) because the standard way of parsing it, (a && b) = (c && d), is almost certainly not useful.)

So today I thought to myself, wait... why stop there? Couldn't we have a suffix operator that works the same way? I wasn't sure if the generic code I had written for handling arbitrary operators would handle a low-precedence suffix operator, so I did an experiment and confirmed that yes, I could add one successfully. The operator I added is called :|, and to support it I made the following changes:

1. Add unit test in Les3PrinterAndParserTests.PrecedenceOverrideEffect:

    Exact("a = b :| * c", F.Call(S.Mul, F.Call((Symbol)"':|suf", F.Call(S.Assign, a, b)), c));
   

2. Add a new entry for the operator in Les2PrecedenceMap.PredefinedSuffixPrecedence (the precedence on the left side of :| its precedence is -10, lower than any other operator, and on the right, the it's 111, higher than any other operator; the latter number has no effect on the parser but it helps the printer print correctly. The final two numbers -10, -10 indicate that the precedence should be treated as -10 for miscibility checking):

    protected static readonly Map<object, Precedence> PredefinedSuffixPrecedence =
    	new MMap<object, Precedence>() {
    		{ S.PreInc,     P.Primary }, // ++, never mind that it's called "pre"inc
    		{ S.PreDec,     P.Primary }, // --
    		{ S.PreBangBang,P.Primary }, // !!
    		{ (Symbol)"':|", new Precedence(-10, 111, -10, -10) }, // :|
    	}.AsImmutable();
   

3. Change the lexer (Les3Lexer.GetOpNameAndType) to treat the new operator (and derived operators such as :%|) as a PreOrSufOp instead of a NormalOp (a normal op can be a prefix operator or a binary operator, but not a suffix operator):

    else if (first == ':' && last == '|')
    	tt = TokenType.PreOrSufOp;
   

Happily, it worked perfectly, except that the printer doesn't want to add a space before :| (probably since none of the existing suffix ops need a space there.)

However, is there any value in adding an operator like this? Perhaps not, because yesterday I just added two new arrowlike operators with very low precedence: |> and <|. These operators can be used to similar effect:

a = b <| c // parsed as `(a = b) <| c`

So I think I'll just rip out these changes.