Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120840
MIME-Version: 1.0
In-Reply-To: <51a97131-f64e-4939-9339-24e70873fe32@app.fastmail.com>
References: <CAOfzkkxrQOje274RMUW8kv13vBmtNSNd_D9Bq_SJeDEBVA8i7Q@mail.gmail.com>
 <CAJpLVh1hhd=zxSz+T4eZdd7eBD-40muU81eFwhmh3e0n7VGwyQ@mail.gmail.com>
 <8055b366-32f1-4d2c-85d0-0cf665e6c8d3@app.fastmail.com> <CABAhh3FjjwyZjrpzrES6E1kbRz_czg64-CRxtKw-jkY5JzGYeA@mail.gmail.com>
 <CAJpLVh3BXQ4rB_5WZK7DopesFgwQ2K5xMD_EgWRQ0-Zd4BF_5A@mail.gmail.com> <51a97131-f64e-4939-9339-24e70873fe32@app.fastmail.com>
Date: Tue, 18 Jul 2023 18:47:34 +0200
Message-ID: <CAJpLVh0v9vGq2ytwWDzj9ogT_AUZiW0tptdGN5wuYV=hbSmDiQ@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: someniatko <someniatko@gmail.com>, php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] pipes, scalar objects and on?
From: olleharstedt@gmail.com (=?UTF-8?Q?Olle_H=C3=A4rstedt?=)

2023-07-18 17:13 GMT+02:00, Larry Garfield <larry@garfieldtech.com>:
> On Tue, Jul 18, 2023, at 1:05 PM, Olle H=C3=A4rstedt wrote:
>> 2023-07-18 14:48 GMT+02:00, someniatko <someniatko@gmail.com>:
>>> I am glad this topic arose! I was also planning to write on this topic
>>> to
>>> the internals mailing list, but have abandoned this idea, because I fee=
l
>>> it
>>> might be inconvenient for the real active PHP developers on the list to
>>> receive too many emails from the people which don't actively participat=
e
>>> in
>>> the development itself.
>>>
>>> My interest in the pipe operator might seem a little non-standard -
>>> basically what I'd really want to see is a **nullable** pipe operator!
>>>
>>> There is a popular library github.com/schmittjoh/php-option, which has
>>> 250
>>> MILLION installations. Basically what it provides is a class-wrapper of
>>> a
>>> value of lack thereof: it's either `Some<Type>` or `None`.
>>
>> I'd just like to mention that the Option type comes from FP and it's
>> not necessarily needed in PHP-land where we have flow-sensitive type
>> checkers like Psalm (a nullable type `?int` or such is refined to just
>> `int` after a null check). Flow-sensitive type-checking was not
>> invented when the Option type was first created, so adding it to PHP
>> is basically stepping back in time, from my point of view.
>
> As I've written before[1], there's a lot of overlap in different
> error-flow-control options.  PHP at the moment leans heavily on the "null=
 is
> error and build tooling around that" approach, which has its pros (mainly
> simplicity) and cons (lack of information).  That mostly obviates the nee=
d
> for a Maybe type, but not entirely.  Right now, there is no "null pipelin=
e"
> option in the language like someniako is describing.
>
> In some sense, that's also trivial to do in user-space[2], which leads
> easily to
>
> $foo
>   |> maybe(bar(...))
>   |> maybe(baz(...))
>   |> maybe(beep(...));
>
> Which isn't terrible, but also isn't ideal.  I don't think I'd oppose a
> nullsafe pipe if there's interest (though again, we need interest in pipe=
s
> in general first).
>
> However, that runs into the related problem that Maybe is... the weaker w=
ay
> of handling error context.  In most cases I prefer a Result/Either type,
> which doesn't map cleanly to null handling.  That could be done as a
> user-space monad (as above, with just a class and method or a magic metho=
d
> and dedicated operator).  Doing it more natively would require deeper
> language hooks.  For instance, Rust has the ? suffix on any expression,
> which means "if this evaluates to an Error case Result, just return that
> Result."  That wouldn't fit well in PHP, though.
>
> As I noted in [1], one option would be to allow an object to flag itself =
as
> an error object, and then null-check operators would treat that as null. =
 So
> given $result =3D foo($a)->bar(), if foo() returns an error object then
> $result is assigned to that error object and bar() is never called.  I'm
> still not sure if I like that approach myself, but am open to hear what
> others think.
>
> To get back on topic, I do think a pipe operator and concat operator are
> valuable in their own right, and have ample use cases even without mixing=
 in
> monads or nullables or things like that.  We should add them.  We can
> consider adding more robust branching options as well, (be that >>=3D, ?|=
>, or
> something else), but be aware that beyond the very trivial case that will
> necessarily involve user-space code for many use cases and we'll need to
> support that.  (Which basically comes down to >>=3D and making monadic cl=
asses
> easier to work with, but also runs into the generics problem, and that's =
its
> own mess.)
>
> [1] https://peakd.com/hive-168588/@crell/much-ado-about-null
> [2] https://github.com/Crell/fp/blob/master/src/composition.php#L39
>
> --Larry Garfield
>

Any comment on a pipe (or piped process) as a first-class value? When
you use |> the functions are immediately applied, which might not be
what you want. You can lazify it by wrapping it in a lambda, but I
think that decreases the value of the pipe concept in itself. One
strength is the ability to split the decision about what to glue
together from the decision on how to execute it. You kinda get some
light-weight metaprogramming ability that way.

Well i guess such a pipe-concept is pretty far removed from the simple
pipe operator. :) And also already possible with existing OOP
concepts, callable classes, and now the (...) syntax.

Olle