Currying #37
Comments
Hi, a relevant discussion in the static-land repo fantasyland/static-land#6 /cc @rpominov |
@jgrund Just curious what kind of currying you have in mind? There are two ways to approach it:
There are different sets of trade-offs for this two options in regard of typing code with Flow. |
@rpominov I am thinking of the second option. Both can be represented in flow, though the second in a more complex fashion via overloads. |
I think option 1 is more of a surfacing to user code of what happens in languages that support currying. |
Is the difference between |
I think the advantage of the second version is that it can be transparent: i.e. 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. |
Ultimately, It would be great if currying was not a user-land construct in JS and was part of the language. |
Another question is whether requiring |
@davidchambers OK - evolution is better than revolution. I can live with the second version. |
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. |
Something interesting about currying at the library level. Using the implementation in
If we run
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. |
Thoughts on currying by default a-la Haskell, PureScript, Elm?
The text was updated successfully, but these errors were encountered: