Support C# 9 pattern matching

[qwertie]

I'm already working on this, but I'm thinking I ought to document my plan somewhere. I'm writing notes in the parser, but here I can put up a formatted table of example patterns:

Example Pattern	Loyc tree (EC#/LES2 notation)
_	_
Enum.Value	Enum.Value
2 + 2	2 + 2
>= 2 + 2	@`'>=`(2 + 2)
var x	#var(@``, x)
var (x, y)	#var(@``, (x, y)) (shorthand for #var(@``, @'tuple(x, y)))
var (x, (y, z))	#var(@``, (x, (y, z)))
{ } obj	#var(@'deconstruct(@'tuple()), obj)
List<T>	List!T (shorthand for @'of(List, T) a.k.a. List `'of` T)
List<T> list	#var(List!T, list)
List<T>() list	#var(@'deconstruct(List!T()), list)
List<T> { Count: >0 } x	#var(@'deconstruct(List!T(), Count ::= @`'>`(0)), x)
List<T>() { Count:7 } x	#var(@'deconstruct(List!T(), Count ::= 7), x)
int?	@'of(@`'?`, #int32)
Foo<a, b>?	@'of(@`'?`, @'of(Foo, a, b))
(Foo) { } x	#var(@'deconstruct(@'tuple(Foo)), x)
(Foo) x	@'cast(x, Foo)
(Foo + 0) x	#var(@'deconstruct(@'tuple(Foo + 0)), x)
(a, b)	@'deconstruct(@'tuple(a, b))
(a, b) { Foo: x }	@'deconstruct(@'tuple(a, b), Foo ::= x)
(> 5, (_, _))	@'deconstruct(@'tuple(@`'>`(5), @'deconstruct(@'tuple(_, _))))
Point(X: > 5, Y: 0)	@'deconstruct(Point(X ::= @`'>`(5), Y ::= 0))
Foo({ Length: 2 })	@'deconstruct(Foo(@'deconstruct(@'tuple(), Length ::= 2))
{ X: 1, Y: >0 }	@'deconstruct(@'tuple(), X ::= 1, Y ::= @`'>`(0))
Foo(X: int x) {Y: >4} f	#var(@'deconstruct(Foo(X ::= #var(#int32, x)), Y ::= @`'>`(4)), f)
not null	@'not(null)
not not null	@'not(@'not(null))
>= 'a' and <= 'z'	@'and(@`'>=`('a'), @`'<=`('z'))
0 or 1	@'or(0, 1)
string or List<char>()	@'or(#string, @'deconstruct(List!#char()))

There is no obvious way to map patterns into Loyc trees, and on any given day I might choose a different way to do it. The arbitrary mapping I chose is as follows:

• Patterns of the form var designation, including var (...), become #var(@``, designation).
• Patterns of the form Type varName become #var(Type, varName).
• Recursive destructuring patterns that have an optional type followed by optional parentheses followed by optional braces become a call to 'deconstruct. Although I use the word "optional", obviously, the syntax requires one of the three parts, but you can use empty braces { } which is an empty destructuring pattern. #deconstruct's first argument includes both the type name and all destructuring patterns that are in parentheses. I observed that C# makes no distinction between foo is Foo and foo is Foo(): if you define a public void Deconstruct() method, writing new Foo() is Foo() does not cause it to be called. I decided to make the Loyc tree identical in both cases: @'is(foo, @'deconstruct(Foo())).
• Relational patterns that start with one of < > <= >= become a unary operator op(expr) where op is an identifier with one of the names '< '> '<= '>= respectively. For example >15>>2 becomes @'>(15>>2).
• Expression and type patterns are represented as themselves, so if a pattern is not one of the above forms, it must be an expression or a type.

There is lots of overlap between patterns and ordinary expressions, but here are some examples showing how patterns differ from normal C# or EC# expressions:

• Type(Foo<Bar, Bar>Baz): As a pattern, Type takes only one argument, but as an expression, it takes two. I tried defining integer variables called Foo, Bar and Baz, but this didn't change the compiler's mind (it would have been very surprising if this had made a difference, because nothing else in the grammar has semantic feedback.)
• {} x: a variable declaration.
• (1, 2) {} x: also a variable declaration
• (> 0, name: <= Foo.Bar): relational prefix operators.
• not Foo<A,B> and not IBar<A,B>: special word operators
• Foo[,] and Foo<,> are not valid expressions in C# (they are allowed in EC#, but as a type or pattern Foo[,] parses to @'of(@'[,], Foo), whereas if it is an expression, it parses to @'suf[](Foo, @, @).
• In EC#, foo (a) { b; } is a valid expression equivalent to foo (a, { b; }). In pattern braces, the separator between items is comma, not semicolon, and foo (a) { b } has a different meaning than foo (a, { b }).
• In a "constant expression" pattern, certain operators like ++, --, => and ? : are syntax errors (if you nest the expression in parens, ? : becomes available but ++ -- => remain unavailable), and & | ^ && || are all unusuable after a prefix relational operator, e.g. x switch { <= 2 & 3 => 7 } is a syntax error, though parens around 2 & 3 makes it valid. I was disappointed that I was unable to find out whether the pattern in x switch { (P) ++ when - 1 > 0 => 0, _ => 1 } meant ((P)++) when (-1 > 0) or (((P) ++when) - 1) > 0.

[qwertie]

The Loyc tree for 'deconstruct is designed to mirror the Loyc tree for 'new:

Expression	Loyc tree
new Foo(arg) { Prop = 5 }	@'new(Foo(arg), Prop = 5)
Foo(arg) { Prop: 5 } pattern	@'deconstruct(Foo(arg), Prop ::= 5)

The existing structure of 'new turned out to be a boon for syntactic pattern-matching, as in this example:

define #var(__var, $name = new $T($(..args)) { $(..initializers) }) {
    $T $name = new $T($args) { $initializers };
}

// Input:
__var x = new List<SomeSortOfUnreasonablyLongTypeName>();
// Output:
List<SomeSortOfUnreasonablyLongTypeName> x = new List<SomeSortOfUnreasonablyLongTypeName>();

Although this example appears to require a list of initializers, it matches new-expressions with no initializers, because the underlying Loyc tree is the same for (e.g.) new Foo { } and new Foo(). In practice this is better than needing to handle "has initializer block" and "does not have initializer block" separately, so I expect it is best to have the same sort of structure in patterns.

Note that plain C# puts a number of restrictions on the kinds of expressions allowed in a pattern context:

• ordinary calls like Math.Abs(3) cannot be used because they are ambiguous with (positional) patterns. Putting the call in parentheses doesn't really help, as (Math.Abs(3)) is still a positional pattern.
• the operators ?: ++ -- => produce syntax errors
• nullable types (not to mention pointer types) produce syntax errors
• there are additional limitations in the context of an is-expression or a relational pattern, e.g. <= 2 & 3 is a syntax error.

Enhanced C# doesn't absolutely need to respect these restrictions, but traditionally, I've done my best to guarantee that (1) printer output always round-trips correctly and (2) if two Loyc trees are different from each other (ignoring trivia) the printer will produce different output for the two trees. It might not be easy to maintain these guarantees for patterns, though, and it's certainly questionable whether it's worth my time.

Enhanced C# already defined its own (dramatically simpler, but no less capable) pattern-matching syntax before C# 7 was published. I'll have to rip out the existing feature, which will be disruptive to existing Enhanced C# code, especially the matchCode macro. I have no plan yet for the transition. An obvious starting point is to support C# 9 patterns in the context of the is and switch operators, but not in the context of case. This reduces disruption because matchCode is based on a list of case statements without EC#-style patterns. match does rely on EC# patterns, but probably my 5 users (or however many there are) won't miss the feature given that it is designed to achieve precisely what C# 9 patterns do anyway.

[qwertie]

Whew. The parser is passing a battery of tests... now for the printer.

At this point I don't think round-tripping everything is feasible, because (just as in C# itself) the structure of an expression like a is (Boo, Coo) has changed. Previously it was a tuple type, but now it's a deconstruction (@'is(a, @'deconstruct((Boo, Coo))) rather than @'is(a, (Boo, Coo))). However if somebody constructs the tree @'is(a, (Boo, Coo)) and gives it to the printer, I think it should still print a is (Boo, Coo): this doesn't round-trip, but it does what the user probably expects. Plus, I just don't want to spend as much time on the printer as I did on the parser. At this point I'm thinking, if somebody passes in a tree like @'is(x, Foo[77].etc), I'm just going to print x is Foo[77].etc even though it'll break the parser, because doing it properly will just take too long.

If you need proper round-tripping, LES can do that for you.

[qwertie]

I think it's ready...