Comment by cjbgkagh

Comment by cjbgkagh 8 days ago

Are you saying you prefer Ocaml to F# or C# to F#? Your example was indeed inelegant but it is also poorly designed as you take 4 lines to reproduce a function that is already built in, people can poorly design code in any language.

shortrounddev2 7 days ago

I'm saying that I wish computation blocks looked better in F#. Instead of:

    let foo id = async {
      let! bar = getBar id
      return bar
    }

I would prefer

    let async foo id =
      let! bar = getBar id
      bar

or even something like

    let async foo id =
        getBar! id

So that computation blocks don't feel like you're switching to an entirely different language. Just wrap the ugliness in the same syntactic sugar that C# does. As it is, C# can achieve arrow syntax with async methods more elegantly than F# can:

    async Task<string> foo(int id) => await getBar(id);

This, to me, is also part of a larger problem of F# introducing unique keywords for specific language functions instead of reusing keywords, like

    member this.Foo = ...

and

    member val Foo = ...

Reply View 6 replies

cjbgkagh 7 days ago

Your criticism is rather incoherent and it is difficult for me to make sense of it.
You don't even have to use the computation block for that and can use the built in functions as I mentioned earlier and gave 3 examples of.
You're both complaining about extra keywords while trying to make the case of adding yet another one. Thus your complaint boils down to F# not picking the exact keywords that you like - that the language is not specialized to exactly how you want to use it. In language design there are always tradeoffs but I'm unable to see how your suggestions would improve the language in the general case or even in your specific case.
Computation expressions are a generalized concept which are there to add the exact kind of syntactic sugar that you're after. It's better than C# in that you can create your own as a first class concept in addition to using the built in ones. It's there for the exact purpose of creating mini-embedded DSLs, the very thing you're complaining about is the exact point of it.
F# is not for everyone, nor should it be.

Reply View | 5 replies
- shortrounddev2 7 days ago
  
  > You're both complaining about extra keywords while trying to make the case of adding yet another one
  I did no such thing. async is already a keyword in F#, I'm just saying they should drop the brackets and remove the required return statement.
  > In language design there are always tradeoffs but I'm unable to see how your suggestions would improve the language in the general case or even in your specific case
  It would make the language easier to read, for one, and would reduce the amount of specialized syntax needed for specific features. It would preserve the original ML-style syntax for an extremely common operation and not force users into wrapping anything upstream of an async call in a computation block, which is the ugliest syntax feature of F#
  > Computation expressions are a generalized concept which are there to add the exact kind of syntactic sugar that you're after
  I understand that, and my argument is they failed to do so. The syntax looks bad. They could keep it for all I care, but they should add even more sugar on top to make it not look so bad.
  
  Reply View | 4 replies
  
  cjbgkagh 7 days ago
  
  'async' is not a keyword in F#, it's a builder instance no different to the ones that you can create. It's just built in to the standard library.
  The return statement is only required if you want to return something form the computation expression. In your example you use async { let! x = f(); return x}, which can be reduced to async { return! f()}, which can be reduced to f().
  The rest is your opinion that I don't agree with.
  
  Reply View | 3 replies