I do need to keep my pre-existing biases in check here too, and it's good you're having a go at challenging the status quo.
Conversation
How hard would it be to create an alternate, Elm-style syntax for Reason? As somebody who writes a great deal of Rust, I kind of feel type signatures on top make much more sense for a type-driven programming style, as does dropping parens. Makes the code much cleaner and lighter.
3
1
1
Sweet. Would be interesting to see how people react to comparisons if they could easily switch between them!
3
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 `(@@)`.
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
Is't `|>` becoming popular even in JavaScript? There is a TC39 proposal for it.
1
Show replies