The case that I was trying to make to the ReasonML designers --- unsuccessfully I guess --- is that the best way to lower the barrier-to-entry for JS coders to ReasonML is to stick with the ML tradition of writing k-ary functions with k-tuples and *simply not tell them about currying at all* until they're up and running. As I understand it, their parser unrolls the tuples

let f = (x, y, z) => ... become let f = x => y => z => ...

Then whenever an unsuspecting JS coder accidentally calls f with too few arguments, f(a, b), they don't get an understandable type error because f(a, b) is of function type and they get some weird error with arrows in it.
I hope they'll revisit this issue but it sounds like a done deal.
Bob


On Wed, Dec 13, 2017 at 12:39 PM, Hendrik Boom <hendrik@topoi.pooq.com> wrote:
On Wed, Dec 13, 2017 at 09:22:05AM +0100, Sebastien Ferre wrote:
>
> The Scala notation is an interesting alternative, IMO.
>
> They have two notations, f(x,y) and f(x)(y), the latter being the
> curryfied version allowing partial application.
>
> They also have a notation for partial application
> of the non-curryfied form,  f(x,_) and f(_,y), with
> the advantage that not only the last argument can missing.

I understand currying; I first encountered it in the 60's when
studying combinatory logic.

But I find it a nuisance in progrmming in OCaml, becuse it oftern
happens by accident, and results in mysterious type errors, or none at
all.

That's why I'd like to see currying only happen explicitly; most of
the time Ocaml figures I'm currying it's a mistake.

-- hendrik

--
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs