Currying about flow-static-land HOT 11 OPEN

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.

from flow-static-land.

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

from flow-static-land.

Hi,

a relevant discussion in the static-land repo fantasyland/static-land#6

/cc @rpominov

from flow-static-land.

@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.

from flow-static-land.

@rpominov I am thinking of the second option.

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

from flow-static-land.

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

from flow-static-land.

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?

from flow-static-land.

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.

from flow-static-land.

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

from flow-static-land.

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.

from flow-static-land.

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.

from flow-static-land.