Fsharpplus: Add polyvariadic curry/uncurry functions

Created on 10 Jul 2019  路  14Comments  路  Source: fsprojects/FSharpPlus

Most helpful comment

I think so, all these kind of polyvariadic functions are type directed, for instance for the uncurryN function the first argument is the one that is used to infer and thus specialize the function.

There are some scenarios where this is not a problem, but some abstractions where you pass the specific curry functions are type directed by the curry arity itself.

Of course, if we had to keep only one, by adding type annotations to curryN you can get the other versions (actually infinite versions) but that might become a bit verbose and defeat the purpose.

All 14 comments

Looks like we're adding a few polyvariadic functions to F#+ which makes me wonder what's the best way to organize them, specially for these ones which currently exists.

a. We could rename the existing curry and uncurry to curry2 and uncurry2.

b. Another way would be to prefix them with g or suffix with N then we'll have:

  1. curry and uncurry for 2-arguments (2-uples)
  2. curry3and uncurry3 for 3-arguments (3-uples) and so on for more
  3. curryN and uncurryNfor N-arguments (N-uples)

Which would become as a de-facto naming convention.

Is there any benefit to have both versions?

I think so, all these kind of polyvariadic functions are type directed, for instance for the uncurryN function the first argument is the one that is used to infer and thus specialize the function.

There are some scenarios where this is not a problem, but some abstractions where you pass the specific curry functions are type directed by the curry arity itself.

Of course, if we had to keep only one, by adding type annotations to curryN you can get the other versions (actually infinite versions) but that might become a bit verbose and defeat the purpose.

Yes, makes sense. uncurryN doesn't work when you mean uncurry for tuples only.

I think I would vote for the (b) naming convention, but that implies we'll have to rename memoize to memoizeN as well.

I agree I think b) makes most sense.

Perhaps time to schedule a 2.0 release with those changes?

Did the memoization function make it to nuget?

I think a) makes the most sense but b) is the least breaking change

@lfr

I think a) makes the most sense but b) is the least breaking change

For sure this makes sense in isolation. Now if we take into account existing code base, curry function exists in many places (including Haskell's prelude) as a 2 argument curry.

Then more generally speaking, many standard functions take the name without specifying number of arguments for 2 arguments, or better to say the minimum number of arguments (ie: map, zip, lift) , while polyvariadic functions are less common, as they are more exotic.

The memoization method is not published to nuget as far as I can see. So next potential version is 1.1 馃槃

@gusty makes sense to me, I recast my vote for b)

Looks like we're converging to b) @cmeeren do you have any thoughts (since you did the memoization PR) ?

No strong opinions from me. Do what you think is best! 馃憤

Was this page helpful?
0 / 5 - 0 ratings