[Vote] Pipe operator v2

  115333
July 6, 2021 17:13 larry@garfieldtech.com ("Larry Garfield")
I have opened the vote on the Pipe operator RFC:

https://wiki.php.net/rfc/pipe-operator-v2

The vote will close on 20 July.

-- 
  Larry Garfield
  larry@garfieldtech.com
  115335
July 6, 2021 23:54 bobwei9@hotmail.com (Bob Weinand)
Hey Larry,

there's still ongoing discussion on the semantics, and mirroring implementation defined semantics from the implementation into the RFC is not the way to go. The RFC should discuss reasons of why semantics were chosen and the implementation then be decided upon it. Describing it as "design artifact" is not okay.
I'm voting no at this point, to force it to be postponed to PHP 8.2 with proper thought of what the semantics shall be. Possibly the semantics are fine (I tend to disagree with the current ones, but that's rather point for discussion), but they are not discussed enough, especially as they only got described in the RFC in the last minutes before the vote.

Bob

> Am 06.07.2021 um 19:13 schrieb Larry Garfield <larry@garfieldtech.com>: > > I have opened the vote on the Pipe operator RFC: > > https://wiki.php.net/rfc/pipe-operator-v2 > > The vote will close on 20 July. > > -- > Larry Garfield > larry@garfieldtech.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php >
  115352
July 7, 2021 14:32 larry@garfieldtech.com ("Larry Garfield")
On Tue, Jul 6, 2021, at 6:54 PM, Bob Weinand wrote:
> Hey Larry, > > there's still ongoing discussion on the semantics, and mirroring > implementation defined semantics from the implementation into the RFC > is not the way to go. The RFC should discuss reasons of why semantics > were chosen and the implementation then be decided upon it. Describing > it as "design artifact" is not okay. > I'm voting no at this point, to force it to be postponed to PHP 8.2 > with proper thought of what the semantics shall be. Possibly the > semantics are fine (I tend to disagree with the current ones, but > that's rather point for discussion), but they are not discussed enough, > especially as they only got described in the RFC in the last minutes > before the vote.
The semantics around how references work with pipes have been consistent from April 2020 until today, aside from a few hours from when Nikita suggested blocking it to when I determined it was more work than I could handle on short notice. The RFC description of those semantics was clear and accurate for that entire time, modulo those few hours, and there was a test confirming them. So "they only got described in the RFC in the last minutes before the vote" is factually inaccurate. Wanting to think deeper about how references should work is fine, but please don't misrepresent the situation. How references work in this RFC has been explicitly defined since it was first introduced 15 months ago, and the first pushback on it at all as far as I recall came less than 48 hours before the feature freeze, leaving no time to have such a discussion. --Larry Garfield
  115453
July 17, 2021 14:48 ocramius@gmail.com (Marco Pivetta)
Hey Larry,

I just voted "NO" on this: it took me a long time to decide, because I've
been vouching for pipe-alike operators myself for a while.

The reason why I voted "no" is that this is feasible with a `pipe(callable
$first, callable ...$piped)` function, without having to add syntax/AST for
it.

Type safety for such a closure would still be very messy, but feasible with
some macro-based templating of docblocks.

The simplistic approach to this is simple composition (the `.` you
mentioned):

```php
/**
 * @template TIn of mixed
 * @template TOut of mixed
 *
 * @param callable(TIn): TIntermediate $first
 * @param callable(TIntermediate): TOut $piped
 *
 * @return callable(TIn): TOut
 * @return TOut
 */
function pipe(callable $first, callable $piped): callable
{
}
```

 Pol Dellaiera  (https://github.com/drupol) has done a lot of work around
this stuff, specifically the type inference bit, in
https://github.com/loophp/combinator , so I see hope to get better types at
a later stage.

Therefore:

 * userland runtime **implementation** is trivial
 * userland type-safe definition is non-trivial, but not insurmountable


Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/


On Tue, Jul 6, 2021 at 7:13 PM Larry Garfield <larry@garfieldtech.com>
wrote:

> I have opened the vote on the Pipe operator RFC: > > https://wiki.php.net/rfc/pipe-operator-v2 > > The vote will close on 20 July. > > -- > Larry Garfield > larry@garfieldtech.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
  115456
July 17, 2021 15:59 larry@garfieldtech.com ("Larry Garfield")
On Sat, Jul 17, 2021, at 9:48 AM, Marco Pivetta wrote:
> Hey Larry, > > I just voted "NO" on this: it took me a long time to decide, because I've > been vouching for pipe-alike operators myself for a while. > > The reason why I voted "no" is that this is feasible with a `pipe(callable > $first, callable ...$piped)` function, without having to add syntax/AST for > it. > > Type safety for such a closure would still be very messy, but feasible with > some macro-based templating of docblocks. > > The simplistic approach to this is simple composition (the `.` you > mentioned): > > ```php > /** > * @template TIn of mixed > * @template TOut of mixed > * > * @param callable(TIn): TIntermediate $first > * @param callable(TIntermediate): TOut $piped > * > * @return callable(TIn): TOut > * @return TOut > */ > function pipe(callable $first, callable $piped): callable > { > } > ``` > > Pol Dellaiera (https://github.com/drupol) has done a lot of work around > this stuff, specifically the type inference bit, in > https://github.com/loophp/combinator , so I see hope to get better types at > a later stage. > > Therefore: > > * userland runtime **implementation** is trivial > * userland type-safe definition is non-trivial, but not insurmountable > > > Marco Pivetta
Hi Marco. Thank you for your explanation, even if I naturally disagree. Out of curiosity, what sort of additional power/capability/flexibility/etc. would, in your mind, justify pipe or similar being a native feature? PHP has a *ton* of native features that *could* be done in user space, or are simply syntax sugar, but still wildly popular and useful as native syntax. What is your heuristic for that? (The fact that there are 3-4 user space implementations of pipe-like behavior, all incompatible, is one of the reasons why I think standardizing it into a common core syntax *is* a good idea, though I know others disagree.) --Larry Garfield
  115514
July 20, 2021 09:12 ocramius@gmail.com (Marco Pivetta)
Hey Larry,

On Sat, Jul 17, 2021 at 6:00 PM Larry Garfield <larry@garfieldtech.com>
wrote:

> Hi Marco. Thank you for your explanation, even if I naturally disagree. > > Out of curiosity, what sort of additional > power/capability/flexibility/etc. would, in your mind, justify pipe or > similar being a native feature? PHP has a *ton* of native features that > *could* be done in user space, or are simply syntax sugar, but still wildly > popular and useful as native syntax. What is your heuristic for that? > > (The fact that there are 3-4 user space implementations of pipe-like > behavior, all incompatible, is one of the reasons why I think standardizing > it into a common core syntax *is* a good idea, though I know others > disagree.) >
I think the pipe operator as a **custom** operator made sense when we had the entire discussion around placeholder parameters (`$$`) to be used in the pipeline. As a plain "chain of functions with one input parameter and one output", it makes little sense to have it as a custom construct, as it only adds complexity to the AST. Greets, Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
  115532
July 20, 2021 14:53 olleharstedt@gmail.com (=?UTF-8?Q?Olle_H=C3=A4rstedt?=)
2021-07-20 11:12 GMT+02:00, Marco Pivetta <ocramius@gmail.com>:
> Hey Larry, > > On Sat, Jul 17, 2021 at 6:00 PM Larry Garfield <larry@garfieldtech.com> > wrote: > >> Hi Marco. Thank you for your explanation, even if I naturally disagree. >> >> Out of curiosity, what sort of additional >> power/capability/flexibility/etc. would, in your mind, justify pipe or >> similar being a native feature? PHP has a *ton* of native features that >> *could* be done in user space, or are simply syntax sugar, but still >> wildly >> popular and useful as native syntax. What is your heuristic for that? >> >> (The fact that there are 3-4 user space implementations of pipe-like >> behavior, all incompatible, is one of the reasons why I think >> standardizing >> it into a common core syntax *is* a good idea, though I know others >> disagree.) >> > > I think the pipe operator as a **custom** operator made sense when we had > the entire discussion around placeholder parameters (`$$`) to be used in > the pipeline. > > As a plain "chain of functions with one input parameter and one output", it > makes little sense to have it as a custom construct, as it only adds > complexity to the AST.
That is the idiomatic implementation, though. Hacklang is the odd man out with $$. Olle
  115457
July 17, 2021 16:10 internals@lists.php.net ("Levi Morrison via internals")
> Pol Dellaiera (https://github.com/drupol) has done a lot of work around > this stuff, specifically the type inference bit, in > https://github.com/loophp/combinator , so I see hope to get better types at > a later stage.
I don't see a pipe combinator in there, but maybe I can't see it through the poor formatting of the table... It's been a while since I delved deep into type theory, but I am not aware of any language which supports this sort of type safety in functions while being variadic. Are you aware of any? The only ones I am aware of use macros, which are different as they are evaluated and expanded at compile time.
  115534
July 20, 2021 15:32 larry@garfieldtech.com ("Larry Garfield")
On Tue, Jul 6, 2021, at 12:13 PM, Larry Garfield wrote:
> I have opened the vote on the Pipe operator RFC: > > https://wiki.php.net/rfc/pipe-operator-v2 > > The vote will close on 20 July.
The vote has now closed. Yes: 11 No: 17 The RFC has been declined. --Larry Garfield