Currying

[jgrund]

Thoughts on currying by default a-la Haskell, PureScript, Elm?

[gcanti]

Hi,

a relevant discussion in the static-land repo https://github.com/rpominov/static-land/issues/6

/cc @rpominov

[rpominov]

@jgrund Just curious what kind of currying you have in mind? There are two ways to approach it:

1. We can make this work fn(a)(b), but not this fn(a, b).
2. We can make both fn(a)(b) and fn(a, b) work.

There are different sets of trade-offs for this two options in regard of typing code with Flow.

[jgrund]

@rpominov I am thinking of the second option.

Both can be represented in flow, though the second in a more complex fashion via overloads.

[jgrund]

I think option 1 is more of a surfacing to user code of what happens in languages that support currying.

[ivenmarquardt]

Is the difference between fn(a)(b) and fn(a, b) really that big that it justifies the second version, which would require a programmatic solution and thus an additional layer of complexity?

[jgrund]

I think the advantage of the second version is that it can be transparent: i.e. fn(a, b).

The first version takes two invocations regardless if the user plans to fully satisfy the arguments.

That said, I suppose it could be said the first is more explicit.

[jgrund]

Ultimately, It would be great if currying was not a user-land construct in JS and was part of the language.

[davidchambers]

Is the difference between fn(a)(b) and fn(a, b) really that big that it justifies the second version, which would require a programmatic solution and thus an additional layer of complexity?

Another question is whether requiring fn(a)(b) would prevent some potential users from adopting the project. The answer is undoubtedly yes, since programmers are just as irrational (i.e. guided by emotion) as the rest of the population. If wide adoption is a goal, requiring )( is inadvisable.

[ivenmarquardt]

@davidchambers OK - evolution is better than revolution. I can live with the second version.

[rjmk]

I'm for 2 over 1 and uncurried over 2.

I'm for 2 over 1 because of the complexity @ivenmarquardt has mentioned. I've had a lot of headaches with functions curried Ramda-style (maybe this problem is solvable, maybe not).

I'm for uncurried over 2 because of what @davidchambers said.

[jgrund]

Something interesting about currying at the library level. Using the implementation in Fun.js, consider:

const result = maybe.map(
  (a):number => a + 1,
  maybe.inj(3)
);

const result2 = maybe.map(
  (a):string => a + 'bar',
  maybe.inj('foo')
);

const curryMap = fun.curry(maybe.map);

const result3 = curryMap(
  (a):number => a + 1,
  maybe.inj(3)
);

const result4 = curryMap(
  (a):string => a + 'bar',
  maybe.inj('foo')
);

If we run flow suggest:

-const result = maybe.map(
+const result: Maybe<number> = maybe.map(
   (a):number => a + 1,
   maybe.inj(3)
 );

-const result2 = maybe.map(
+const result2: Maybe<string> = maybe.map(
   (a):string => a + 'bar',
   maybe.inj('foo')
 );

 const curryMap = fun.curry(maybe.map);

-const result3 = curryMap(
+const result3: Maybe<number | string> = curryMap(
   (a):number => a + 1,
   maybe.inj(3)
 );

-const result4 = curryMap(
+const result4: Maybe<number | string> = curryMap(
   (a):string => a + 'bar',
   maybe.inj('foo')
 );

When currying, flow is taking a union of the possibilities, which it doesn't in the non-curried version.

This seems like a large issue, as the buildup of types from usage is problematic.