README.md example confusion with `curry`

Is your feature request related to a problem? Please describe. Based on my understanding of what curry should do, I would expect it to behave like this:

const uncurriedAdd = (x, y) = x + y
const curriedAdd = curry( add )
console.log(curriedAdd(20, 4))
// [Function]

Just as it would if I did:

const properlyCurriedAdd = x => y => x + y
console.log(properlyCurriedAdd(20, 4))
// [Function]

Describe the solution you’d like This is very convenient behavior. I’m only requesting to change the README.md to explicitly use the curry’d form first and then explain the convenience. i.e.

safeDivide(20)(0)
//=> Nothing

// for convenience, the function returned by curry() can also be called with
safeDivide(20, 0)
//=> Nothing

[dalefrancis88]

@sunwukonga would you count this issue as closed?

[dalefrancis88]

So the policy we’ve tended to adopt throughout the frameworks docs is to favour the unary type signature, // curriedAdd :: Number -> Number -> Number -> Number It’s then generally understood that you can have the added benefit or calling a curried function with n parameters and all parameters are applied to the underlying curried function. I think if you kept the example simple, as you have, you can then show that a curried function can be invoked with n arguments. It might also be nice to show the behaviour for optional parameters here as well maybe?