[RFC] Auto-currying about nspl HOT 4 CLOSED

Wow, this is a strange coincidence: I was just the other day thinking about how great it would be if PHP had currying at its core. It would even be mostly backwards compatible, save for code relying on ArgumentCountErrors being thrown and such 😄.

Thinking on this, I noticed that currying is probably what I am missing. I have been working around sprinkling partial everywhere by using the with function, like so:

<?php

private function calculateAverageRating(): float
{
    if (!count($this->ratings)) {
        return 0.0;
    }
​
    with($this->ratings)
        ->map(methodCaller('getScore')),
        ->reduce(sum) / count($this->ratings),
    );
}

The problem with this is, is that it will not work with the lazy variants, as I have now moved the division out of the function composition and thus required that the result be immediately evaluated, which does work nicely in your currying and original example.

I think your rpartial(div, count($this->ratings)) could possibly be rewritten to flipped(div)(count($this->ratings)) to benefit from currying, though flipped would probably need to be rewritten, as it blindly tries to immediately call the flipped function, which will then still pass the first argument as actual first argument if you don't supply all arguments immediately.

I wanted to raise the concern that there already is a separate version of most functions to make them lazy. Adding a separate curried version of all functions would probably explode into a whopping four versions of all functions. Though I must say that I have been wondering if it would be feasible to just drop the non-lazy variants of the library in a new major release altogether. They could then also be made curried and it would reduce maintenance costs considerably.

Evaluating lazy functions is automatically done by looping over them anyway and, if you really need arrays as output, iterator_to_array already exists (which, takes a Traversable, which Generator implements). I'm also skeptical of any major performance difference between generators and arrays, but I don't think it will make much of a difference unless you have huge collections, which I doubt will happen often.

Most functions are also wrapped in the ds.php classes for convenience. Though, if we get currying, it's pretty much as short as using the with keyword, and makes staying inside the function bubble less awkward, I'm wondering if it may not just be a better idea to drop ds.php as well.

Now if only we had operator overloading so I can overload the dot operator to do function composition and the bitwise or operator to pipe functions 😄.

from nspl.

Evaluating lazy functions is automatically done by looping over them anyway and, if you really need arrays as output, iterator_to_array already exists (which, takes a Traversable, which Generator implements).

There are other libraries of similar purpose using iterators everywhere by default and they are really painful to work with in real-life scenarios. iterator_to_array calls all around the code, because most standard library functions don't accept iterators.

from nspl.

Though I must say that I have been wondering if it would be feasible to just drop the non-lazy variants of the library in a new major release altogether.

You don't have any larger application using this library, do you?

from nspl.

As for currying by default: if you like Ramda, there are already enough PHP libraries going the Ramda way (see my list). I think NSPL has a clear profile, is quite good at what it is, and shouldn't try to become something else with the next major release.

from nspl.