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
>