c/programming_languages · by soc@programming.dev · 1y

Unified Condition Expressions

https://soc.me/languages/unified-condition-expressions

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.

8 points · 7 comments · view on lemmy.world

7 Comments

mobotsar@sh.itjust.works · 3 pts · 1y

A quite decent syntax and an excellent domain name!

tyler@programming.dev · 2 pts · 1y (1 reply)

How does $person get set?

soc@programming.dev · 2 pts · 1y

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"

considerealization@lemmy.ca · 2 pts · 1y (1 reply)

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"

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"

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

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.dev · 1 pts · 1y

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.

armchair_progamer@programming.dev · 1 pts · 1y (1 reply)

This looks very similar to The Ultimate Conditional Syntax, although that's for ML so it doesn't have the nice syntax for chaining method calls.

soc@programming.dev · 1 pts · 1y

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