I simply don't understand why people like C style syntax so much.
But the thing to realize is that this syntax change isn't for folks and you and me. We'll be fine with either.
Did you consider having a 'beginner mode' Reason, then flipping a switch to compare it to compare it to the non-parened version is?
Don't take my words for it: https://github.com/facebook/reason/pull/1299#issuecomment-30... https://realworldocaml.org/v1/en/html/imperative-programming... https://drup.github.io/2016/08/02/difflists/ https://bucklescript.github.io/bucklescript/Manual.html#_cal...
I'm jumping into this conversation early on because too often this point is raised and turns into an uncharitable interpretation of our motivations, e.g. "look at these js programmers, not understanding the beauty of currying". Rest assured that we do (and that we're not just js programmers), and that the Merlin and BuckleScript authors know very well what they're doing. Hope this clarifies things a bit.
Interesting about argument syntax + effects. I've mainly used currying in pure languages. Is it about accidentally calling an effectful function multiple times? Is the idea here that you are conservatively treating everything as effectful with the uncurried syntax (before algebraic effects land), then will make pure stuff curried in order to attract people to use pure functions where possible?
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. :/
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.
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.
_This_, I do think, is a fair argument. It's indeed an accidental drawback of the syntax revamp. Though there are very realistic way to prevent the confusion: https://github.com/reasonml-community/error-message-improvem...
Regarding optimization: see the BuckleScript link on explicit uncurrying. The impact is very visible: the compiler analysis for specializing for uncurrying best-effort, and when it bails, it looks like this: https://reasonml.github.io/try/?reason=PQKgBA5g9lAmYGMCGBnAp... which calls https://github.com/BuckleScript/bucklescript/blob/2a66960b5a.... How many function calls did your curried call just turn into, in the second case?
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.
Can you explain this? Currying and side-effects seem orthogonal to me.
I agree though. Honestly, getting worked up over such fluff as where parens go, which whitespace to use, what line curly braces go on is a minor annoyance of mine. The human brain is capable of parsing some pretty obscure stuff (see: human language) just fine.
Same goes for a lot of Haskell code.
"A lot", not "all": yeah indeed at least you can tweak the punctuation towards more ergonomic (aka more productive) aesthetics. What you describe is just the unfortunate result of many-perhaps-most (early) Haskellers / the std-lib authors being married to established-but-ugly academic operator symbols instead of boldly redesigning them for green-field programmers of this (then, newly from-scratch) programming language.
Once swapping out the built-in `.` for <. and `>>>` for .> and $ for <| and & for |> it all comes a breeze to read (I mean, in comparison), about on par with Elm/F#. Now I've never heard anyone complain that Elm code is unreadable, it's a good example for other MLs to follow.
The rest of what you describe is just due to these hackers being heavily into their own combinator libraries, truly if you code all day, just as there shouldn't be a need to elaborately spell out "function" and "return" and so forth all the time in imperative, they feel less need to spell out all the map/filter/reduce English words all the time. At some point, all the names describe "symbolic relations of sorts" and I wouldn't fault anyone for philosophizing: "that which is specific to my program should be named as words, but that which is 'primitive' / generalized / commonly used among all sorts of programs could just as well be just symbols" ;)
I mean I hack in Go all days right now and it's fun --- lots of parens & braces don't exactly kill me. Here, tweaking one's colour scheme easily solves this in one fell swoop and takes just under a minute tops. No need to go "ML-ish FP" just for the lack of curlies. =)