3 ms·

It's the other way around. 'async'-annotated methods in C# enable 'await'ing on task-shaped types. It is bespoke and async-specific. There is nothing wrong wit

It's the other way around. 'async'-annotated methods in C# enable 'await'ing on task-shaped types. It is bespoke and async-specific. There is nothing wrong with it but it's necessary to acknowledge this limitation. let!, and!, return!, etc. keywords in F# are generic - you can build your own state machines/coroutines with resumable code, you can author completely custom logic with CEs. I'm not sure what led you to believe the opposite. `await Task.Delay` in C# is `do! Task.Delay` in F#. `let! response = http.SendAsync` is for asynchronous calls that return a value rather than unit. In the same vein, seq is another CE that is more capable than iterator methods with yield return: let values = seq { // yield individual values for i in 1..10 -> i // yield a range, merged into the sequence yield! [11..20] // note the exclamation mark } Adding support for this in C# would require explicit compiler changes. CEs are generic and very powerful at building execution blocks with fine control over the behavior, DSLs and more. Reference: https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/computation-expressions https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...

shortrounddev2 2y ago
I'm somewhat already aware of these considerations, it's just that when you're working in web development, a huge amount of your code is async and this means that a large part of the code is wrapped up in these computation expressions that I think are just plain ugly
- miffy900 2y ago
  What's so ugly about them? I don't code in F#, but I do in C# and after reading about them I wish C# had something similar.
shakna 2y ago
> It is bespoke and async-specific. There is nothing wrong with it but it's necessary to acknowledge this limitation. I would disagree. If you need to have a bespoke set of syntax, then something is not integrated where it should be. The language design should not be such that you are writing things differently, depending on the paradigm that you're handling. That's not something that occurs in every language, so it isn't essential that it exists. We can acknowledge the differences in a way that alerts the programmer, without forcing the programmer to switch syntaxes back and forth when moving between the paradigms. async/await is one method, Promises another, etc. A different syntax is a much, much higher cognitive load.
- neonsunset 2y ago
  I cannot make sense of this reply. Different languages have different syntax. Support of asynchronous code and of its composition is central to C#, which is why it does it via async/await and Task<T> (and other Task-shaped types). Many other languages considered this important enough to adopt a similar structure to their own rendition of concurrency primitives, inspired by C# either directly or indirectly. Feel free to take issue with the designers of these languages if you have to. F#, where async originates from, just happens to be more "powerful" as befits an FP language, where resumable code and CEs enable expressing async in a more generalized fashion. I'm not sold on idea that C# needs CEs. It already has sufficient complexity and good balance of expressiveness.
  - shakna 2y ago
    Different languages have different syntax, but most do not have a separate syntax inside themselves. A function is generally a function. They do adopt various structures - but those are structures, not syntax. I'm not sure you've understood that was my point.
    - neonsunset 2y ago
      [edited out the swipe] Do-notation-like 'await' is not for calling functions, it is for acting on their return values - to suspend the execution flow until the task completes.
      - shakna 2y ago
        I've written patches for F#. I do know what the hell I'm talking about. However, the compiler does not, has never, required that it does things via a different syntax. In fact, in the early branches before that was adopted, it didn't! The same behaviour was seen in those branches. This behaviour you expect, was never something that had to be. It was something chosen to simplify the needs of the optimiser, and in fact cut the size of code required in half. It was to reduce the amount of code needed to be maintained by the core team. And so 1087 [1] was accepted. So perhaps you might need to read more into the process of the why and how async was introduced into C# and F#. It was a maintenance team problem. It was a pragmatic approach for them - not something that was the only way that this became a possibility. As said, in the original branch for using tasks... > Having two different but similar ways of creating asynchronous computations would add some cognitive overhead (even now there are times when I am indecisive between using async or mailbox for certain parallelism/concurrency scenarios). [0] [0] https://github.com/fsharp/fslang-suggestions/issues/581 https://github.com/fsharp/fslang-suggestions/issues/581 [1] https://github.com/fsharp/fslang-design/blob/main/FSharp-6.0/FS-1087-resumable-code.md https://github.com/fsharp/fslang-design/blob/main/FSharp-6.0...

shortrounddev2 2y ago

I'm somewhat already aware of these considerations, it's just that when you're working in web development, a huge amount of your code is async and this means that a large part of the code is wrapped up in these computation expressions that I think are just plain ugly

miffy900 2y ago
What's so ugly about them? I don't code in F#, but I do in C# and after reading about them I wish C# had something similar.

shakna 2y ago

> It is bespoke and async-specific. There is nothing wrong with it but it's necessary to acknowledge this limitation. I would disagree. If you need to have a bespoke set of syntax, then something is not integrated where it should be. The language design should not be such that you are writing things differently, depending on the paradigm that you're handling. That's not something that occurs in every language, so it isn't essential that it exists. We can acknowledge the differences in a way that alerts the programmer, without forcing the programmer to switch syntaxes back and forth when moving between the paradigms. async/await is one method, Promises another, etc. A different syntax is a much, much higher cognitive load.

neonsunset 2y ago
I cannot make sense of this reply. Different languages have different syntax. Support of asynchronous code and of its composition is central to C#, which is why it does it via async/await and Task<T> (and other Task-shaped types). Many other languages considered this important enough to adopt a similar structure to their own rendition of concurrency primitives, inspired by C# either directly or indirectly. Feel free to take issue with the designers of these languages if you have to. F#, where async originates from, just happens to be more "powerful" as befits an FP language, where resumable code and CEs enable expressing async in a more generalized fashion. I'm not sold on idea that C# needs CEs. It already has sufficient complexity and good balance of expressiveness.
- shakna 2y ago
  Different languages have different syntax, but most do not have a separate syntax inside themselves. A function is generally a function. They do adopt various structures - but those are structures, not syntax. I'm not sure you've understood that was my point.
  - neonsunset 2y ago
    [edited out the swipe] Do-notation-like 'await' is not for calling functions, it is for acting on their return values - to suspend the execution flow until the task completes.
    - shakna 2y ago
      I've written patches for F#. I do know what the hell I'm talking about. However, the compiler does not, has never, required that it does things via a different syntax. In fact, in the early branches before that was adopted, it didn't! The same behaviour was seen in those branches. This behaviour you expect, was never something that had to be. It was something chosen to simplify the needs of the optimiser, and in fact cut the size of code required in half. It was to reduce the amount of code needed to be maintained by the core team. And so 1087 [1] was accepted. So perhaps you might need to read more into the process of the why and how async was introduced into C# and F#. It was a maintenance team problem. It was a pragmatic approach for them - not something that was the only way that this became a possibility. As said, in the original branch for using tasks... > Having two different but similar ways of creating asynchronous computations would add some cognitive overhead (even now there are times when I am indecisive between using async or mailbox for certain parallelism/concurrency scenarios). [0] [0] https://github.com/fsharp/fslang-suggestions/issues/581 https://github.com/fsharp/fslang-suggestions/issues/581 [1] https://github.com/fsharp/fslang-design/blob/main/FSharp-6.0/FS-1087-resumable-code.md https://github.com/fsharp/fslang-design/blob/main/FSharp-6.0...