Sweet. Would be interesting to see how people react to comparisons if they could easily switch between them!
Conversation
imo, having function application use parens instead of a space introduces a lot of syntactic niceties - Foo(Bar(Baz), Bloop, fip + fop) looks nicer to my eyes than Foo (Bar Baz) Bloop (fip + fop)
Plus, OCaml's oddities around type application and variants being uncurried...
2
3
Another thing to look out for - any time someone uses @@ in OCaml, that's a sign that they really would have preferred the paren style calling concrete syntax. It achieves the same precedence.
2
1
is `@@` like `(<|)` and `($)` in Elm/Haskell respectively?
1
I think so.
1
Pretty convinced that `(<|)`, `(|>)`, `(<<)`, `(>>)` is the way to go for application and composition operators now, thanks to F# and Elm. Makes things a ton clearer for folks than `@@` and `(.)`/`($)`, which provide no directional hint to people.
1
I do agree, in an OCaml/ML style syntax. For Reason v3, <| is no longer needed I think. |> is still useful.
1
That kind of hints at an assymmetry in the design though? Would have been interesting to see if histories diverged if `(<|)` was available, or if the more readable reverse composition operator, `(|>)`, was preferred over `(@@)`.
1
Either way, it's nowhere nears as familiar as x(y, z). Many developers even have a visceral reaction to snake_case not being camelCase. Imagine how much more adverse the response would be to an ML syntax full of <| |>. I just make the observations here.
2
3
Hey, just want to say, sorry for my strong comments, they were a little heated in hindsight, and it was kind of a silly of me. Thanks for all the work you are doing, you're doing a great job for all of us, and it's important to make tricky choices along the way!
1
1
We're all working hard and experimenting. I'm still not sold on the approach, but I know you mean well, and it's impossible to make everyone happy, especially when it comes to something quite subjective like syntax.
And I know there's customization coming in the future which sounds exciting, but understand you can't do everything overnight! I'm excited to keep watching what the community does - it's always quite inspiring!
These Reason guys are doing an awesome job and I'm grateful that they're working on it. Sometimes a simple solution is hiding in plain sight: as far as lowering the barrier-to-entry for JSers, why not simply write all of the tutorial/introductory examples in uncurried style?
2
2
So they see
let add(x, y) = x + y;
and not
let add x y = x + y;
I was pretty surprised when I read that
let rec map = (f, xs) => ...
was actually the curried form of the map function! Very confusing IMHO.
1
1
Show replies