documentation: mention Ramda in introduction

[davidchambers]

Is this an improvement, @dmitriz?

[dmitriz]

I would make it a separate paragraph, but maybe it is just me ;)

[dmitriz]

What it still does not say:

• def takes a function that must be uncurried

• the output is the corresponding curried function that behaves exactly as the one created with Ramda's curry

[davidchambers]

def takes a function that must be uncurried

This is implied by the examples, but not actually stated. Please submit a pull request to make this clear if you feel so inclined.

the output is the corresponding curried function that behaves exactly as the one created with Ramda's curry

R.curry returns a function which does no type checking, so we'd need to be more specific about what behaviour def has in common with R.curry. I think it's clearer to actually explain the common behaviour (as we currently do) rather than point to Ramda. Furthermore, Ramda is not a specification: it's an ad hoc, informally-specified, bug-ridden, slow implementation of half of Haskell (and there's a mug to prove it). Let's not aim at a moving target. There's even an open pull request for removing placeholder support from R.curry (ramda/ramda#1843).

[dmitriz]

I have now tried few more tests just to get some confidence: https://github.com/dmitriz/sanctuary-def/blob/more-tests/test/index.js#L339

It looks indeed that all Ramda's functionality is there, well done! ;)

This one I cannot fix as it does not tell me the actual-expected values: https://github.com/dmitriz/sanctuary-def/blob/more-tests/test/index.js#L418

(There is also some strange linting error with arrow functions that I don't understand)

In any case, I suggest to commit this PR first, then I can try to make it even more clear.

• def takes a function that must be uncurried

This is implied by the examples, but not actually stated. Please submit a pull request to make this clear if you feel so inclined.

I am all for explicit over implicit. Removes unnecessary confusion, leaves less room for long discussions :blink:, saves your time too ;)

the output is the corresponding curried function that behaves exactly as the one created with Ramda's curry

R.curry returns a function which does no type checking, so we'd need to be more specific about what behaviour def has in common with R.curry. I think it's clearer to actually explain the common behaviour (as we currently do) rather than point to Ramda.

Totally agree.

Furthermore, Ramda is not a specification: it's an ad hoc, informally-specified, bug-ridden, slow implementation of half of Haskell (and there's a mug to prove it). Let's not aim at a moving target. There's even an open pull request for removing placeholder support from R.curry (ramda/ramda#1843).

Hahaha ;) Yes, it is hard to argue with the mug. Must be true then 😄

Nothing against good parts from Haskell, hopefully no bad parts (such as pairs vs tuples inconsistency).

Totally agree that Ramda (or anything else) should not be used as spec.

About feature removals ... I'd be very careful as it can always annoy some folks...