[RFC] [Discussion] Operator functions

  100475
September 8, 2017 21:41 ajf@ajf.me (Andrea Faulds)
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.

Thanks!
-- 
Andrea Faulds
https://ajf.me/
  100476
September 8, 2017 22:45 ocramius@gmail.com (Marco Pivetta)
On Fri, Sep 8, 2017 at 11:41 PM, Andrea Faulds <ajf@ajf.me> wrote:

> 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/opera > tor_functions > > Please tell me what you think and suggest any potential improvements or > anything you think might have been an omission. > > Thanks! > -- >
This is bloody brilliant! Stupid example, but: function factorial(int $i) { return array_reduce(range(1, $i), "*", 1); } I see great potential in this: moving away from operators as weird syntactic sugar and in the direction of operators as functions (what they actually are). Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
  100478
September 9, 2017 01:31 fsb@thefsb.org ("Tom Worster")
On 8 Sep 2017, at 17:41, Andrea Faulds wrote:

> 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
  100484
September 9, 2017 09:27 ilija.tovilo@me.com
I also love this idea!
This and short arrow functions and I’m golden (in terms of closures at least) :)

Regards


On 9 Sep 2017, 03:31 +0200, Tom Worster <fsb@thefsb.org>, wrote:
> On 8 Sep 2017, at 17:41, Andrea Faulds wrote: > > > 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
  100490
September 9, 2017 14:38 nikita.ppv@gmail.com (Nikita Popov)
On Fri, Sep 8, 2017 at 11:41 PM, Andrea Faulds <ajf@ajf.me> wrote:

> 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/opera > tor_functions > > Please tell me what you think and suggest any potential improvements or > anything you think might have been an omission. > > Thanks!
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. 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. 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. 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. Nikita
  100493
September 9, 2017 21:18 ajf@ajf.me (Andrea Faulds)
Hi Nikita,

Nikita Popov wrote:
> On Fri, Sep 8, 2017 at 11:41 PM, Andrea Faulds <ajf@ajf.me> 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/