Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add polyvariadic curry/uncurry functions #155

Closed
gusty opened this issue Jul 9, 2019 · 14 comments
Closed

Add polyvariadic curry/uncurry functions #155

gusty opened this issue Jul 9, 2019 · 14 comments

Comments

@gusty
Copy link
Member

gusty commented Jul 9, 2019

Standalone code is here: https://gist.github.com/gusty/47b53b21548304730341fe4799a1f050

@gusty gusty changed the title Add plyvariadic curry/uncurry functions Add polyvariadic curry/uncurry functions Jul 9, 2019
@gusty
Copy link
Member Author

gusty commented Jul 10, 2019

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.

@wallymathieu
Copy link
Member

Is there any benefit to have both versions?

@gusty
Copy link
Member Author

gusty commented Jul 10, 2019

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.

@wallymathieu
Copy link
Member

wallymathieu commented Jul 10, 2019

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

@gusty
Copy link
Member Author

gusty commented Jul 11, 2019

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

@wallymathieu
Copy link
Member

I agree I think b) makes most sense.

@wallymathieu
Copy link
Member

Perhaps time to schedule a 2.0 release with those changes?

@gusty
Copy link
Member Author

gusty commented Jul 11, 2019

Did the memoization function make it to nuget?

@lfr
Copy link

lfr commented Jul 11, 2019

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

@gusty
Copy link
Member Author

gusty commented Jul 11, 2019

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

@wallymathieu
Copy link
Member

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

@lfr
Copy link

lfr commented Jul 12, 2019

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

@gusty
Copy link
Member Author

gusty commented Jul 12, 2019

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

@cmeeren
Copy link
Contributor

cmeeren commented Jul 12, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants