6 ms·

The Ultimate Conditional Syntax

145 points by azhenley 2y ago

huqedato 2y ago
Elixir already has this - "with". https://www.openmymind.net/Elixirs-With-Statement/ https://www.openmymind.net/Elixirs-With-Statement/ E.g.: with true <- is_email_address?(email), true <- String.length(code) === 6, %EmailConfirmation{} <- EmailConfirmations.get_email_confirmation(email), nil <- EmailAddresses.get_email_address(email), {:ok, user} <- Users.create_user(data), {:ok, email_address} <- EmailAddresses.create_email_address(user, email) do ... else ... end
- ioasuncvinvaer 2y ago
  How does this check exhaustiveness?
- halostatue 2y ago
  I don't think that this is `with` (which is really a series of nested `case` statements with exactly two paths per case). case is_email_address?(email) do true -> case String.length(code) == 6 do true -> case EmailConfirmations.get_email_confirmation(email) do %EmailConfirmation{} -> case EmailAddresses.get_email_address(email) do nil -> case Users.create_user(data) do {:ok, user} -> case EmailAddresses.create_email_address(user, email) do {:ok, email_address} -> # success block fail -> fail end fail -> fail end fail -> fail end fail -> fail end fail -> fail end fail -> case fail do # else conditions end end Elixir will be able to do something closer to `case` exhaustiveness checking with the gradual typing being built, and dialyzer can sort of perform exhaustiveness checking as long as your type specs are written well enough. (I’ve observed two things about `with` statements in Elixir: they should have more than one condition clause, or they should be written as `case` statements; they should not have an `else` clause, as that suggests that error path normalization isn't happening at the right level.) In many ways what's described is much closer to `cond`, except that `cond` is completely open ended except for the required `true` clause, which means that there is absolutely no exhaustiveness checking. I'll admit that I mostly skimmed this and I don't use ML or Haskell, but I couldn't see what benefit this provides over Elixir's `case` or Rust's `match` (recognizing that the former can't do exhaustiveness checking as yet, but `match` absolutely can).
  - lptk 2y ago
    Just check out the paper's Motivaton section (2). In ML you can't write something like this: if e is ... Lit(value) and Map.find_opt(value) is Some(result) then Some(result) ... where the `...` may include many cases and may contain other Lit cases, so that you would need to refactor the whole expression. Haskell's pattern guards can do this, but they can't "split" control-flow in the middle of a case, as in: Lit(value) and Map.find_opt(value) is Some(result) and computation(result) is Left(a) then ... Right(b) then ... but these all fall out completely naturally in the UCS. Also, exhaustiveness Just Works without the need of any type annotation. The system is actually type system agnostic.
    - lptk 2y ago
      PS: there's another point being made on Reddit about cond's right-shift problem: https://www.reddit.com/r/ProgrammingLanguages/comments/1g127oy/the_ultimate_conditional_syntax/lrg36qg/ https://www.reddit.com/r/ProgrammingLanguages/comments/1g127...
      - halostatue 2y ago
        Thank you. I think that I’ll need to read this again with that particular comment in mind, because that makes sense. The limitations of Elixir syntax means it would need to be something more like: ucs do expensive() => and cheap1() -> "branch 1", and cheap2() -> "branch 2", cheap3() -> "branch 3" end There are other ways around it, but it could be fun to try to build a macro in Elixir for the UCS.
  - andrewstuart 2y ago
    My eyes! They burn!
    - halostatue 2y ago
      They should. This nesting is why `with` exists, but even if `cond` and `case` could test for exhaustiveness (they can't currently, and I don't think that `cond` ever could), `with` would not be able to test for exhaustiveness, since there's always two paths described.
clark800 2y ago
Looks very similar to lambda zero syntax (https://github.com/clark800/lambda-zero https://github.com/clark800/lambda-zero): def getNaturalName(tag, globals) if globals.lookup("0") is Just(Global(_, _, term)) if term is Numeral(_, type, _) return Just(Name(getTermTag(type))) error showSyntaxError("0 must be a numeral to use numerals", tag) return Void Though this ultimate conditional syntax is more general because lambda zero only allows one destructuring per conditional to simplify parsing.
- hermanhermitage 2y ago
  Thanks for posting this. Lambda zero looks wonderful. Is there any background information beyond the GitHub repo?
  - clark800 2y ago
    Here's a presentation on it: https://www.slideshare.net/slideshow/embed_code/key/z1PHLexDpvw3Ja https://www.slideshare.net/slideshow/embed_code/key/z1PHLexD... Note: There have been some minor changes to the language since this was made.
mgaunard 2y ago
I don't understand how it's better than traditional pattern matching.
- dan-robertson 2y ago
  With traditional matching there are up to five different things: - if x then y else z. This is roughly like a match with a true and false case but it depends on the language how much that is - match e with { p -> e }. This is the classic pattern match case - if let p = e then x. This is roughly equivalent to (match e with p -> x | _ -> ()) - match e with { p when e -> e }. This is matching with a guard but I’ve counted it as a special case because it doesn’t easily designate into a match because of the binding/evaluation order, and the guard is special because it can only go at the top level of the match clause so it isn’t just a special kind of pattern (though maybe it could be) - let p = e. This is one-case pattern matching used for binding variables or destructuring. The paper proposes a way to make the first four cases obvious parts of one more unified thing, which makes the language potentially simpler and may reduce some weird warts like where guards can go.
  - EPWN3D 2y ago
    There's such a thing as too high an abstraction. Sometimes 4 different operations really are just 4 different operations and not cases of some mega-construct.
    - dan-robertson 2y ago
      I totally agree that can be the case, but I’m not sure it applies that much to the OP.
      - HelloNurse 2y ago
        Sometimes a simple conditional statement grows into something more complex over time and it's nice to keep the same malleable syntax, particularly (as is the case of the article) with good semantic and performance guarantees.
dan-robertson 2y ago
I like that there is this left-to-right flow. I think it’s a bit nicer to read than if-let ordering where the pattern comes before the thing it will be matched against. I think it’s also good for ocaml-style constructor disambiguation, which tends to go in lexical order. Another nice aspect of making guards a less special case is that it avoids complexities in deciding if a binding is unused. I believe this logic was a source of lots of compiler warning bugs in ocaml. This syntax doesn’t seem to solve the following problem with matching where there are two paths to the same binding, (say you have an option in one branch but it isn’t optional in the other, and maybe you’d like to handle both cases with the same code. Currently you can do that with a match (match …) with … pattern. I worry that the semantics around exhaustiveness and mutable values may be confusing, though I guess OCaml already has that problem: type t = { mutable x : bool } let n = function true -> 1 | false -> 0 let f t = match t with | { x = false } when ( t.x <- true; false) -> -1 | { x } -> n x * 2 + n t.x What does t { x = false } return? Similarly if you changed the second case to be two cases instead of binding x?
- lptk 2y ago
  As mentioned in a response to a sibling comment, we plan to support `or`, which should address the problem you mention. (If not, would you have an example of what you mean?) > I worry that the semantics around exhaustiveness and mutable values may be confusing, though I guess OCaml already has that problem Indeed, and it was until very recently a source of unsoundness: https://icfp24.sigplan.org/details/mlworkshop-2024-papers/8/Pattern-matching-on-mutable-values-danger- https://icfp24.sigplan.org/details/mlworkshop-2024-papers/8/...
  - munificent 2y ago
    Oh, wow, that's interesting. We added pattern matching and exhaustiveness to Dart not that long ago, and dealing with exhaustiveness and mutability was a big concern since Dart (unlike more strictly functional languages) generally doesn't avoid mutability. Our solution was that whenever a pattern accesses a property, the language implicitly caches that value. Any future accesses to the same property in that switch statement/expression use the previously cached value. That way, an entire set of switch cases is always operating on an immutable snapshot of data so that exhaustiveness can't be violated by side effects. Spec: https://github.com/dart-lang/language/blob/main/accepted/3.0/patterns/feature-specification.md#side-effects-and-exhaustiveness https://github.com/dart-lang/language/blob/main/accepted/3.0...
breck 2y ago
I love this. Not the implementation, I think one could do better, but the fact that they identified an interesting opportunity: coming up with the Ultimate Conditional Syntax for pattern matching. I would love to see them take one more crack at it, and this time try to think about how to reduce the syntax to the bare minimum. Here's my read/adding of this language to PLDB: https://www.youtube.com/watch?v=UzsDaq0UdnM https://www.youtube.com/watch?v=UzsDaq0UdnM
andyferris 2y ago
The other one I want occassionally is "or". Imagine Left and Right contained data of compatible types, then I'd like to extract that data (regardless of tag) like so: if x is Left(y) or x is Right(y) then ... That way I only need to write the `...` part once. (This could be combined with the rest of the pattern matching machinery in interesting ways, and would probably need to have eager matching / short-circuiting semantics in case both cases match).
- lptk 2y ago
  We definitely want to get into that! Unfortunately it's not completely straightforward. A simple desugaring doesn't work due to our support for intermediate bindings and computations, which we don't want to recompute.
  - HelloNurse 2y ago
    Do you mean something like compiling if (x is Left(Foo(y)) or x is Right(Foo(y))) and (y<5 or z>2) then 5 and destructuring Foo(y) only one time and dealing with parentheses?
upghost 2y ago
Kudos to the authors. It takes some fortitude to try to make a contribution to something as fundamental and ubiquitous as the "if" statement. Appreciate providing the grammar and the thorough explanations, will save a lot of pain when trying to implement!
lou1306 2y ago
Kudos for publishing in OOPSLA, but alas I'm skeptical. This seems to add visual clutter/mental overhead as one needs to parse a decision tree rather than having a "flat" sequence of patterns with the optional when-condition. Also, > all the branches in the corresponding pattern matching expression would need to destructure the pair, even when only one of its components is needed Can't one just bind the unneeded component to _ ? Isn't that actually a good thing, as it clearly self-documents we won't need that value on that branch?
thom 2y ago
There's an online playground for MLscript at: https://hkust-taco.github.io/mlscript/ https://hkust-taco.github.io/mlscript/
- lptk 2y ago
  It's currently badly outdated. There's one specifically for the UCS at https://ucs.mlscript.dev/ https://ucs.mlscript.dev/
andrewstuart 2y ago
This is the ultimate conditional syntax: if (x === 1) console.log(“it’s 1”) The “if” bothers me though, be nice not to have it.
- rlkf 2y ago
  (x === 1) && console.log("it's 1") Note that you've saved exactly no keystrokes, although this is composable into expressions (if you are using some Javascript-derivative; in ML it would typically already be using the if-form).
  - eacnamn 2y ago
    ((x == 1)) && printf 'it'"'"'s 1\n' although I'm not sure how useful this actually is, but it is a nice-to-know
  - andrewstuart 2y ago
    or x === 1 && console.log("it's 1");
ajb 2y ago
This is really cool It reminds me a lot of the kind of flow you get in mathematics sometimes. I guess theorem prover languages may be keen to adopt it. I'd be less keen in a language with side effects, unless the language has a way to restrict it to pure functions
- lou1306 2y ago
  Well, Standard ML was initially designed for a theorem prover, so you're definitely onto something here :)
zelphirkalt 2y ago
> Below, the code on the left is equivalent to the more verbose ML expression on the right: Wait a sec ... ML has the pipe of Elixir? Damn, I didn't know that! I like the brevity, but I don't like the (at least visual) need to indent or whitespace focus. I guess I am too much a sucker for S-expressions now. But a similar structure could probably be written as a macro in a lisp, avoiding any whitespace focus or even dependency on it.
- zeckalpha 2y ago
  Other way around... Elixir has the pipe of ML.
hoosieree 2y ago
They missed one: def agent(data, predicate, fns): ps = map(predicate, data) fs = map(lambda x:fns[x], ps) return map(fs, data) Basically you want to apply one of N functions to each of the items in your data iterable, so you have a predicate to figure out which function to apply first. The degenerate case is when you have just 2 functions and your predicate returns a boolean (0 or 1). This is "agent" from J: https://code.jsoftware.com/wiki/Vocabulary/atdot#agent https://code.jsoftware.com/wiki/Vocabulary/atdot#agent
klauserc 2y ago
C# pattern matching gets very close. I think C# can do everything except for their last example ("splitting conditional prefixes in arbitrary places"). One of the things I miss when switching to Rust. if foo(args) == 0 then "null" |> abs > 100 then "large" < 10 then "small" else "medium" That last syntax took me a while to parse in the paper, but I can imagine numerous places in our everyday code where such syntax would more concisely capture intent.
- plaguuuuuu 2y ago
  I'm wondering if you could use Roslyn to implement your snippet's syntax anyway.
- lptk 2y ago
  Genuine question, as I'm not up to date with C#'s recent developments: can C# do this? if e is ... Lit(value) and Map.find_opt(value) is Some(result) then Some(result) ... where the `...` may include many cases and may contain other Lit cases. Or this variation: ... Lit(value) and Map.find_opt(value) is Some(result) and computation(result) is Left(a) then ... Right(b) then ... ...
- tobbebex 2y ago
  Oh but C# can do even those: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/operators/patterns#relational-patterns https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

145 points by azhenley 2y ago

Elixir already has this - "with". https://www.openmymind.net/Elixirs-With-Statement/ https://www.openmymind.net/Elixirs-With-Statement/ E.g.: with true <- is_email_address?(email), true <- String.length(code) === 6, %EmailConfirmation{} <- EmailConfirmations.get_email_confirmation(email), nil <- EmailAddresses.get_email_address(email), {:ok, user} <- Users.create_user(data), {:ok, email_address} <- EmailAddresses.create_email_address(user, email) do ... else ... end

ioasuncvinvaer 2y ago
How does this check exhaustiveness?
halostatue 2y ago
I don't think that this is `with` (which is really a series of nested `case` statements with exactly two paths per case). case is_email_address?(email) do true -> case String.length(code) == 6 do true -> case EmailConfirmations.get_email_confirmation(email) do %EmailConfirmation{} -> case EmailAddresses.get_email_address(email) do nil -> case Users.create_user(data) do {:ok, user} -> case EmailAddresses.create_email_address(user, email) do {:ok, email_address} -> # success block fail -> fail end fail -> fail end fail -> fail end fail -> fail end fail -> fail end fail -> case fail do # else conditions end end Elixir will be able to do something closer to `case` exhaustiveness checking with the gradual typing being built, and dialyzer can sort of perform exhaustiveness checking as long as your type specs are written well enough. (I’ve observed two things about `with` statements in Elixir: they should have more than one condition clause, or they should be written as `case` statements; they should not have an `else` clause, as that suggests that error path normalization isn't happening at the right level.) In many ways what's described is much closer to `cond`, except that `cond` is completely open ended except for the required `true` clause, which means that there is absolutely no exhaustiveness checking. I'll admit that I mostly skimmed this and I don't use ML or Haskell, but I couldn't see what benefit this provides over Elixir's `case` or Rust's `match` (recognizing that the former can't do exhaustiveness checking as yet, but `match` absolutely can).
- lptk 2y ago
  Just check out the paper's Motivaton section (2). In ML you can't write something like this: if e is ... Lit(value) and Map.find_opt(value) is Some(result) then Some(result) ... where the `...` may include many cases and may contain other Lit cases, so that you would need to refactor the whole expression. Haskell's pattern guards can do this, but they can't "split" control-flow in the middle of a case, as in: Lit(value) and Map.find_opt(value) is Some(result) and computation(result) is Left(a) then ... Right(b) then ... but these all fall out completely naturally in the UCS. Also, exhaustiveness Just Works without the need of any type annotation. The system is actually type system agnostic.
  - lptk 2y ago
    PS: there's another point being made on Reddit about cond's right-shift problem: https://www.reddit.com/r/ProgrammingLanguages/comments/1g127oy/the_ultimate_conditional_syntax/lrg36qg/ https://www.reddit.com/r/ProgrammingLanguages/comments/1g127...
    - halostatue 2y ago
      Thank you. I think that I’ll need to read this again with that particular comment in mind, because that makes sense. The limitations of Elixir syntax means it would need to be something more like: ucs do expensive() => and cheap1() -> "branch 1", and cheap2() -> "branch 2", cheap3() -> "branch 3" end There are other ways around it, but it could be fun to try to build a macro in Elixir for the UCS.
- andrewstuart 2y ago
  My eyes! They burn!
  - halostatue 2y ago
    They should. This nesting is why `with` exists, but even if `cond` and `case` could test for exhaustiveness (they can't currently, and I don't think that `cond` ever could), `with` would not be able to test for exhaustiveness, since there's always two paths described.

clark800 2y ago

Looks very similar to lambda zero syntax (https://github.com/clark800/lambda-zero https://github.com/clark800/lambda-zero): def getNaturalName(tag, globals) if globals.lookup("0") is Just(Global(_, _, term)) if term is Numeral(_, type, _) return Just(Name(getTermTag(type))) error showSyntaxError("0 must be a numeral to use numerals", tag) return Void Though this ultimate conditional syntax is more general because lambda zero only allows one destructuring per conditional to simplify parsing.

hermanhermitage 2y ago
Thanks for posting this. Lambda zero looks wonderful. Is there any background information beyond the GitHub repo?
- clark800 2y ago
  Here's a presentation on it: https://www.slideshare.net/slideshow/embed_code/key/z1PHLexDpvw3Ja https://www.slideshare.net/slideshow/embed_code/key/z1PHLexD... Note: There have been some minor changes to the language since this was made.

mgaunard 2y ago

I don't understand how it's better than traditional pattern matching.

dan-robertson 2y ago
With traditional matching there are up to five different things: - if x then y else z. This is roughly like a match with a true and false case but it depends on the language how much that is - match e with { p -> e }. This is the classic pattern match case - if let p = e then x. This is roughly equivalent to (match e with p -> x | _ -> ()) - match e with { p when e -> e }. This is matching with a guard but I’ve counted it as a special case because it doesn’t easily designate into a match because of the binding/evaluation order, and the guard is special because it can only go at the top level of the match clause so it isn’t just a special kind of pattern (though maybe it could be) - let p = e. This is one-case pattern matching used for binding variables or destructuring. The paper proposes a way to make the first four cases obvious parts of one more unified thing, which makes the language potentially simpler and may reduce some weird warts like where guards can go.
- EPWN3D 2y ago
  There's such a thing as too high an abstraction. Sometimes 4 different operations really are just 4 different operations and not cases of some mega-construct.
  - dan-robertson 2y ago
    I totally agree that can be the case, but I’m not sure it applies that much to the OP.
    - HelloNurse 2y ago
      Sometimes a simple conditional statement grows into something more complex over time and it's nice to keep the same malleable syntax, particularly (as is the case of the article) with good semantic and performance guarantees.

dan-robertson 2y ago

I like that there is this left-to-right flow. I think it’s a bit nicer to read than if-let ordering where the pattern comes before the thing it will be matched against. I think it’s also good for ocaml-style constructor disambiguation, which tends to go in lexical order. Another nice aspect of making guards a less special case is that it avoids complexities in deciding if a binding is unused. I believe this logic was a source of lots of compiler warning bugs in ocaml. This syntax doesn’t seem to solve the following problem with matching where there are two paths to the same binding, (say you have an option in one branch but it isn’t optional in the other, and maybe you’d like to handle both cases with the same code. Currently you can do that with a match (match …) with … pattern. I worry that the semantics around exhaustiveness and mutable values may be confusing, though I guess OCaml already has that problem: type t = { mutable x : bool } let n = function true -> 1 | false -> 0 let f t = match t with | { x = false } when ( t.x <- true; false) -> -1 | { x } -> n x * 2 + n t.x What does t { x = false } return? Similarly if you changed the second case to be two cases instead of binding x?

lptk 2y ago
As mentioned in a response to a sibling comment, we plan to support `or`, which should address the problem you mention. (If not, would you have an example of what you mean?) > I worry that the semantics around exhaustiveness and mutable values may be confusing, though I guess OCaml already has that problem Indeed, and it was until very recently a source of unsoundness: https://icfp24.sigplan.org/details/mlworkshop-2024-papers/8/Pattern-matching-on-mutable-values-danger- https://icfp24.sigplan.org/details/mlworkshop-2024-papers/8/...
- munificent 2y ago
  Oh, wow, that's interesting. We added pattern matching and exhaustiveness to Dart not that long ago, and dealing with exhaustiveness and mutability was a big concern since Dart (unlike more strictly functional languages) generally doesn't avoid mutability. Our solution was that whenever a pattern accesses a property, the language implicitly caches that value. Any future accesses to the same property in that switch statement/expression use the previously cached value. That way, an entire set of switch cases is always operating on an immutable snapshot of data so that exhaustiveness can't be violated by side effects. Spec: https://github.com/dart-lang/language/blob/main/accepted/3.0/patterns/feature-specification.md#side-effects-and-exhaustiveness https://github.com/dart-lang/language/blob/main/accepted/3.0...

breck 2y ago

I love this. Not the implementation, I think one could do better, but the fact that they identified an interesting opportunity: coming up with the Ultimate Conditional Syntax for pattern matching. I would love to see them take one more crack at it, and this time try to think about how to reduce the syntax to the bare minimum. Here's my read/adding of this language to PLDB: https://www.youtube.com/watch?v=UzsDaq0UdnM https://www.youtube.com/watch?v=UzsDaq0UdnM

andyferris 2y ago

The other one I want occassionally is "or". Imagine Left and Right contained data of compatible types, then I'd like to extract that data (regardless of tag) like so: if x is Left(y) or x is Right(y) then ... That way I only need to write the `...` part once. (This could be combined with the rest of the pattern matching machinery in interesting ways, and would probably need to have eager matching / short-circuiting semantics in case both cases match).

lptk 2y ago
We definitely want to get into that! Unfortunately it's not completely straightforward. A simple desugaring doesn't work due to our support for intermediate bindings and computations, which we don't want to recompute.
- HelloNurse 2y ago
  Do you mean something like compiling if (x is Left(Foo(y)) or x is Right(Foo(y))) and (y<5 or z>2) then 5 and destructuring Foo(y) only one time and dealing with parentheses?

upghost 2y ago

Kudos to the authors. It takes some fortitude to try to make a contribution to something as fundamental and ubiquitous as the "if" statement. Appreciate providing the grammar and the thorough explanations, will save a lot of pain when trying to implement!

lou1306 2y ago

Kudos for publishing in OOPSLA, but alas I'm skeptical. This seems to add visual clutter/mental overhead as one needs to parse a decision tree rather than having a "flat" sequence of patterns with the optional when-condition. Also, > all the branches in the corresponding pattern matching expression would need to destructure the pair, even when only one of its components is needed Can't one just bind the unneeded component to _ ? Isn't that actually a good thing, as it clearly self-documents we won't need that value on that branch?

thom 2y ago

There's an online playground for MLscript at: https://hkust-taco.github.io/mlscript/ https://hkust-taco.github.io/mlscript/

lptk 2y ago
It's currently badly outdated. There's one specifically for the UCS at https://ucs.mlscript.dev/ https://ucs.mlscript.dev/

andrewstuart 2y ago

This is the ultimate conditional syntax: if (x === 1) console.log(“it’s 1”) The “if” bothers me though, be nice not to have it.

rlkf 2y ago
(x === 1) && console.log("it's 1") Note that you've saved exactly no keystrokes, although this is composable into expressions (if you are using some Javascript-derivative; in ML it would typically already be using the if-form).
- eacnamn 2y ago
  ((x == 1)) && printf 'it'"'"'s 1\n' although I'm not sure how useful this actually is, but it is a nice-to-know
- andrewstuart 2y ago
  or x === 1 && console.log("it's 1");

ajb 2y ago

This is really cool It reminds me a lot of the kind of flow you get in mathematics sometimes. I guess theorem prover languages may be keen to adopt it. I'd be less keen in a language with side effects, unless the language has a way to restrict it to pure functions

lou1306 2y ago
Well, Standard ML was initially designed for a theorem prover, so you're definitely onto something here :)

zelphirkalt 2y ago

> Below, the code on the left is equivalent to the more verbose ML expression on the right: Wait a sec ... ML has the pipe of Elixir? Damn, I didn't know that! I like the brevity, but I don't like the (at least visual) need to indent or whitespace focus. I guess I am too much a sucker for S-expressions now. But a similar structure could probably be written as a macro in a lisp, avoiding any whitespace focus or even dependency on it.

zeckalpha 2y ago
Other way around... Elixir has the pipe of ML.

hoosieree 2y ago

They missed one: def agent(data, predicate, fns): ps = map(predicate, data) fs = map(lambda x:fns[x], ps) return map(fs, data) Basically you want to apply one of N functions to each of the items in your data iterable, so you have a predicate to figure out which function to apply first. The degenerate case is when you have just 2 functions and your predicate returns a boolean (0 or 1). This is "agent" from J: https://code.jsoftware.com/wiki/Vocabulary/atdot#agent https://code.jsoftware.com/wiki/Vocabulary/atdot#agent

klauserc 2y ago

C# pattern matching gets very close. I think C# can do everything except for their last example ("splitting conditional prefixes in arbitrary places"). One of the things I miss when switching to Rust. if foo(args) == 0 then "null" |> abs > 100 then "large" < 10 then "small" else "medium" That last syntax took me a while to parse in the paper, but I can imagine numerous places in our everyday code where such syntax would more concisely capture intent.

plaguuuuuu 2y ago
I'm wondering if you could use Roslyn to implement your snippet's syntax anyway.
lptk 2y ago
Genuine question, as I'm not up to date with C#'s recent developments: can C# do this? if e is ... Lit(value) and Map.find_opt(value) is Some(result) then Some(result) ... where the `...` may include many cases and may contain other Lit cases. Or this variation: ... Lit(value) and Map.find_opt(value) is Some(result) and computation(result) is Left(a) then ... Right(b) then ... ...
tobbebex 2y ago
Oh but C# can do even those: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/operators/patterns#relational-patterns https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...