Language Design: Unified Condition Expressions – Introduction
soc.me
Idea

A design that subsumes the various syntactic forms of

  • if statements/expressions
  • switch on values
  • match on patterns and pattern guards
  • if-let constructs

and scales from simple one-liners to complex pattern matches.

  • considerealization@lemmy.ca
    2·
    2 months ago

    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.

    • soc@programming.devOPEnglish
      1·
      7 days ago

      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

      • very likely still has if then else in the language, thus making it not unified
      • desperately tries to emulate functionality with guards that simply comes out of the box with my approach
      • relies on the ultimate hack of “match on unit”, because match is very limited in which coding patterns it can express

      Also, 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.

    • soc@programming.devOP
      2·
      2 months ago

      Good catch, that should have been if person in the first line.

      It’s been a left-over from when syntax looked like this:

        is Person("Alice", _)$person then "{$person.age}"
  is Person("Bob", $age)       then "$age"
    • soc@programming.devOPEnglish
      1·
      2 months ago

      The author of that paper hung around in the lang design forum were I originally presented this.