There's a distinction between syntax and semantics though. E.g. Go pushes bad semantics (null values, bad error handling, no generics) in the name of beginner ease, with no transition path to better semantics. Reason pushes 'bad' (JavaScript) syntax but good OCaml semantics in the name of attracting JavaScript devs, with a clear transition path to OCaml syntax should they want to.
Good points. Still weird to have a syntax that is at odds with the underlying semantics, and hopefully it doesn't sow more confusion than it initially solves in the long term.
I still can't get my head around why it would be an optimization problem too, seeing as it would be most using the same underlying AST. Unless they actually translate the pseudo-parameter lists into actual tuples in the parser, forbidding raw, single argument passing. :/
Yes, as far as I know Reason is the first project to try to have auto-currying semantics with tupled syntax. It's definitely a bit of an experiment.
Not sure what optimisation problem you're referring to, Reason and OCaml underlying AST are exactly the same. There are no actual tuples unless the programmer is creating actual tuples.
I think what @chenglou was referring to are issues like the "value restriction" [1] and the need to wrap "uncurried" FFI functions with a function that "adapts" it to curried form, thereby adding a layer of indirection.
Reason does not solve these, they're problems inherent to the underlying language and the choices made. I think the point being made was just that currying isn't a clear step forward, but causes some problems as well.
Yeah, definitely agree that there are trade-offs with currying when mapping it to a compilation target like JS, and I am consistently impressed by Bucklescipt's ability to convert the curried versions of functions to regular JS calls. That said, I do still think that it's worth the trouble!
> Still weird to have a syntax that is at odds with the underlying semantics, and hopefully it doesn't sow more confusion than it initially solves in the long term
Unless you introspect the output (which is actually viable to do in a compiler with clean output, such as BuckleScript), you wouldn't know that your higher-order function accidentally became pretty much 4+ calls instead of one. Now imagine quadrupling every high-order function calls or so. BucklesScript (and native OCaml) do a crazy good job of avoiding this when possible, more so than most, as shown in the snippet's first scenario; the manual even shows guaranteed uncurry if you put the right annotation. But if you want to take advantage of _that_ (and please do), there are other tradeoffs as well, but I digress. In general, the compiled code's speed is as good as you can get for JS output.
The perf point alone is not a pedantic argument as you can see. And you might start wondering about other languages' output for currying. Regarding your other comment: yes, from a typing perspective, currying indeed works out wonderfully for pure languages like Elm and PureScript. But OCaml's not a pure language; we've made other tradeoffs; and context matters.
Not sure about your comment about the AST, but I think you're saying that the situation doesn't get better/worse in the new syntax: this is true, since the syntax revamp is really just that: a syntax change. Which is why I said earlier that I was arguing beside the point. But currying seems to attract so much unbalanced attention in this context that I felt I should address it so that it doesn't overwhelm the rest of the syntax change's purpose. Looking at the rest of the threads, it still did, but I'm glad your reaction has been doubt rather than unreasoned negativity, so thanks for that.
