Add Pattern Matching
MavenRain opened this issue · comments
Self-explanatory . . . from the looks of it, this feature seems like the only one keeping Lobster from being the best programming language in the world!
Well, thanks!
We could make it part of the switch syntax (similar to Rust/ML match):
switch obj:
case Monster { hp, _ }: return hp
case Wall {}: return 10
case Pickup { amount }: return amount
Or it could be made part of function overloading (similar to Haskell etc):
def health(Monster { hp, _ }): return hp
def health(Wall {}): return 10
def health(Pickup { amount }): return amount
The latter seems somewhat pointless though, since you can already write:
def health(m::Monster): return hp
def health(w::Wall): return 10
def health(p::Pickup): return amount
i.e. Lobster already has good support for writing methods together like this (and directly accesssing members), rather than as part of the class definition.
An advantage of pattern matching would be more complex patterns, like:
def health(Monster { hp, Armor { a }}): return hp + a * 10
def health(Monster { hp, SwimSuit { _ }}): return hp - 1
But even that is not that much longer in the current syntax, or can use a helper function that computes armor.
While I generally like pattern matching (I used to absolutely love it when I programmed in Haskell, and have implemented it for several of my past languages, e.g. Bla and Aardappel), I think the "cases are next to eachother" is a much bigger benefit than "you can select on multiple objects at once". The latter is useful very infrequently (optimizers for programming languages are a great example), but not so much in games, Lobster's #1 target field.
Can anyone find a compelling example for games that would be a great improvement on what is currently possible?
If anything, extending the switch with objects would be my choice, since it add the most new functionality to what we already have. Though rather than full on structural pattern matching, I think just object types would maybe also be sufficient:
switch obj:
case Monster: return hp +
switch armor:
case Armor: a
case SwimSuit: -1
case Wall: return 10
case Pickup: return amount
i.e. this would add an implicit variable to each case body where members can be accessed just like a method. But again, that ends up just like alternative syntax for the method code above.
Opinions?
But even that is not that much longer in the current syntax
My main draw for pattern matching is readability; ime pattern matched code isn't often that much shorter than alternative anyway
Can anyone find a compelling example for games that would be a great improvement on what is currently possible?
Depends on what flexibility you're willing to go for. Would this include predicates (ie instead of variable, put in function reference, and pattern matches if for that slot the function returns true) and equality checks on reoccurring variables (ie if I use a for a slot in one place, and a for a slot in another, that it'd only match if both a are equal)?
@arvyy yes, the possible list of pattern matching features is long. One of my past languages did implement the "a second occurrence of the variable means the value must be equal to the first", and that is certainly neat.. question is how useful is it, and how hard or easy to read does it make the resulting code.
Some possible things you can match in a pattern:
- sub objects
- constants
- wildcards
- remainders (of a vector, or arbitrary unmatched fields)
- ranges
- predicate functions
- previously bound variables
- inline conditional expressions
That becomes a whole programming language by itself :)
That all would translate underneath to a "web of if-then-elses and variable definitions"
Pattern matching is great when working with data structures. Compare Haskell and Lobster versions of a btree double rotation, for example. And even this is only possible because I defined a BOA constructor newNode that takes arguments without labels. It's so much clearer what doubleL is doing in the pattern match code.
That said, I understand that data structure implementation is not the main focus of Lobster.
@dcurrie actually, I find those both hard to read.. the pattern makes the incoming data structure easier to read, but relating that to the output data structure being constructed is almost harder in the Haskell version (since you need to relate the individual variables, rather than having a . reference).
That said, I understand that data structure implementation is not the main focus of Lobster.
It is something that ideally every language should be good at, and I certainly would Lobster is, or will be. Games is my example use case, but I certainly want it to be a powerful and fast general purpose language by extension.
Reading the above discussion again, I'd actually be most interested in this form:
switch obj:
case Monster:
return hp +
switch armor:
case Armor: a
case SwimSuit: -1
case Wall:
return 10
case Pickup:
return amount
Which would replace:
if obj is Monster:
return obj.hp +
if obj.armor is Armor:
return obj.armor.a
elif obj.armor is SwimSuit:
return -1
elif obj is Wall:
return 10
elif obj is Pickup:
return obj.amount
Not only is it a big improvement on cluttered syntax, it is simple (the switch selects object type, and brings the type into scope like :: would), it could also actually be a speed improvement when testing many types, though that would require sticking a sub-class index in the type structure since that is common case.
For now, we have exhaustive switch on types, which goes pretty far towards this functionality, is simple and fast!
Example:
lobster/tests/typeswitch.lobster
Lines 6 to 77 in b74f00c
Docs:
lobster/docs/source/language_reference.md
Lines 727 to 750 in b74f00c