[RFC] [Discussion] Operator functions

I also love this idea!
This and short arrow functions and I’m golden (in terms of closures at least) :)

Regards

Hi everyone!

Here's an RFC for a small, simple, self-contained feature with no
backwards-compatibility breaks and which in fact doesn't even touch
the language's syntax (it's 50%+1 eligible!) but which could make PHP
a bit more expressive and consistent, especially with potential later
features. It even has a test designed to impose minimal maintenance
burden while testing a fairly large possibility space!

Anyway, the RFC in question is this:
https://wiki.php.net/rfc/operator_functions

Please tell me what you think and suggest any potential improvements
or anything you think might have been an omission.

Yes!

I have wanted this for many years. In the first programming language in
which I achieved real proficiency, this was vernacular. It would make me
happy to return to it in the language I now use most. An anonymous
function that turns an operator into three lines looks dumb and makes me
sad.

Tom

Hi Nikita,

Nikita Popov wrote:

I like the general idea here, but have some comments.

My main observation is that this proposal is only really useful in
combination with a form of partial application.

Indeed. I think the RFC feels somewhat incomplete without such a
facility. Unfortunately it's not really the right place to add partial
application either (at least, not a generic form thereof). RFCs should
generally cover a single feature.

What I might do is write a separate patch and RFC to add a partial
application function (and probably some other similarly useful things
like composition or currying), then delay voting on this RFC until it's
done.

Passing operators to
array_reduce() is cute, but it's not a major application, especially as we
already have built-in functions for the two common operations (array_sum
and array_product).

Where operators-as-functions really shine is in cases where only one of the
operands is bound. You acknowledge this in the RFC, and provide a few
examples using a (not yet existing) partialApply() function:

// Select only the positive numbers
$positiveSubset = array_filters($numbers, partialApply('>', 0));

However, this code is subtly broken. Partial application (at least without
specifying a more specific behavior) operates from left to right, so this
code would be equivalent to:

// Select only the positive numbers
$positiveSubset = array_filters($numbers, function($n) { return 0 > $n;

});

As such, it would return all negative numbers, not all positive numbers.

You're quite right. This is what happens when I don't bother to test all
my examples actually work first. ;)

This is a general issue of partial application in combination with
operators: For the operations that do not commute, you nearly always want
to bind the right operand, not the left.

This is indeed an interesting issue. In the case of > of course you
can just use < instead, but it would be better to have a more general
solution.

An idea I had the other day was that PHP's arrays could solve this
problem. Perhaps partialApply('>', [1 => 0]) would bind the second
parameter, and partialApply('>', [0]) would bind the first.

For my own purposes, I define an operator() function as follows:
https://github.com/nikic/iter/blob/master/src/iter.fn.php#L60

This function either accepts a single argument such as operator('+'), in
which case it is essentially equivalent to this proposal. Or it accepts two
arguments, in which case the right operand will be bound, such as
operator('>', 0).

I wonder if providing such a function might not be a better solution to
this problem. It also has the additional advantage that it can be easily
polyfilled in older PHP versions.

That's an interesting way to do it, and I can see the benefit of doing
it that way. Though I feel it gets rid of the thing that I particularly
liked about the current proposal (versus various other ideas that never
made it to the RFC stage), which that it's concise, simple, and doesn't
single out operators from other functions (no special function or
language construct you need to use). The downside is of course it can't
be polyfilled, but given people are already writing wrapper functions
anyway, it doesn't bother me so much.

Thanks for your response!

--
Andrea Faulds
https://ajf.me/