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

Curry the functions #51

Open
dakom opened this issue Jan 25, 2018 · 3 comments
Open

Curry the functions #51

dakom opened this issue Jan 25, 2018 · 3 comments

Comments

@dakom
Copy link
Contributor

dakom commented Jan 25, 2018

I think all the function arguments should be curried so that we can call them either as (a,b,c) or a => b => c

Since we know the arity of all these functions, we can use an internal curry2, curry3 etc. rather than rely on inspecting the number of arguments etc.

Anyone opposed to this idea?

@huanhulan
Copy link
Member

huanhulan commented Jan 25, 2018

@dakom use the type definition of Haskell style is great, but that will need extra effort for the sodium's users to use and understand it since they are not using the Haskell and the Sodium is the frp lib for non-Haskell communities.

@dakom
Copy link
Contributor Author

dakom commented Jan 25, 2018

Right, by "currying" I mean like the way Ramda does it where you can provide the arguments in either style. It's a little more work on the library side, but that way it's usable in both styles.

In other words, the user is free to call it either like (a,b,c) or a => b => c. There's no obligation to use it like the latter.

(fwiw I'm getting more and more used to using unary functions everywhere... only a matter of time before I go full Haskell, hehe)

@huanhulan
Copy link
Member

@dakom oh, I see what you mean, I think it is a good idea now.

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

No branches or pull requests

2 participants