4 ms·
I'm in the process of writing my a functional utility library myself, and having thought about these things for a while, I think letting everyone curry things t
by clux 14y ago
I'm in the process of writing my a functional utility library myself, and having thought about these things for a while, I think letting everyone curry things themselves make things less intelligent.
For example:
Udon.elem(2, [1, 2, 3]) === true;
As it stands this is simply an accessor for Array.prototype.indexOf. If people know how to use that, this alias is relatively useless unless you want to compose. And even then, you could always compose around the expression, or with a method on the prototype of the result (Number in this case).
However, it's very useful to have a curried version of it so that it can be used in filters:
[1,2,3,4,3,2].filter($.elem([2,4])); // [ 2, 4, 2 ]
This maintains your current javascript indexOf usage, but allows a higher order use that I think should be the default for this function.
If you want you JavaScript to look more like Haskell, then your way makes more sense, but having to write Udon.curry everywhere sort of takes away from that cleanliness you are trying to recreate. I prefer to not mess with existing semantics too much because of it. For reference, here's my library: https://github.com/clux/interlude#usage https://github.com/clux/interlude#usage
- ionfish 14y ago> having to write Udon.curry everywhere sort of takes away from that cleanliness you are trying to recreate. This is true, and I considered your approach when writing functions like `elem`. There were two reasons for this. Firstly, I wanted to avoid introducing more closures than necessary. Secondly, I wanted to keep the source code reasonably transparent (if admittedly rather terse). There is definitely a place for your approach, and it may even be the better one in practise. It's hard to say without writing large projects in both.