A design that subsumes the various syntactic forms of
if
statements/expressionsswitch
on valuesmatch
on patterns and pattern guardsif
-let
constructs
and scales from simple one-liners to complex pattern matches.
A design that subsumes the various syntactic forms of
if
statements/expressionsswitch
on valuesmatch
on patterns and pattern guardsif
-let
constructsand scales from simple one-liners to complex pattern matches.
Isn’t
match
already such a unified expression? Especially once you extend matches with guards, it seems to me like this is a solved problem. E.g.,if x == 1.0 then "a" else "x"
is
match x with | 1.0 -> "a" | _ -> "b"
and
if x == 1.0 then "a" 2.0 then "b" else "z"
is (and IMO reads much clearer this way):
match x with | 1.0 -> "a" | 2.0 -> "b" | _ -> "z"
and
if xs .isEmpty then "e" .contains(0,0) then "n" else "z"
is
match () with | _ when x.isEmpty -> "e" | _ when x.contains(0,0) then "n" | _ -> "z"
and
if person .age < 18 then 18 is Person("Alice", _) then person.age is Person("Bob", let age) then age else -1
is
match person with | _ when person.age < 10 -> 18 | Person("Alice", _) -> person.age | Person("bob", age) -> age | _ -> -1
.
Finally,
if person is Person("Alice", let age) then age else -1
Would be the simple
match person with | Person("Alice", age) -> age | _ -> -1
Seems to me this reads more clear in general and has less magic. Plus, it’s already implemented in a bunch of languages.
Sure, there are some worse/more limited predecessors – my design was partially motivated by a desire to improve upon these.
For instance, that ML-derivative you are using for your examples
if then else
in the language, thus making it not unifiedmatch
is very limited in which coding patterns it can expressAlso, none of the examples are “more clear” or “have less magic”:
Maybe they are more “familiar” to you personally, but that’s about it.
Too me they just look clunky, full of accidental complexity and trying to work around a poor/limited language design.