Re: [PHP-DEV] [Vote] Pipe operator v2

This is only part of a thread. view whole thread
  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.