Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120831
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-531-gfdfa13a06d-fm-20230703.001-gfdfa13a0
Mime-Version: 1.0
Message-ID: <e70f5b7f-3911-4f0b-9942-3e825e7bf89c@app.fastmail.com>
In-Reply-To: 
 <CAJpLVh2t5Y7CzYTJZxLViCYpgncuJg3i4v==q1gye1m-iR4QPQ@mail.gmail.com>
References: 
 <CAOfzkkxrQOje274RMUW8kv13vBmtNSNd_D9Bq_SJeDEBVA8i7Q@mail.gmail.com>
 <CAJpLVh1hhd=zxSz+T4eZdd7eBD-40muU81eFwhmh3e0n7VGwyQ@mail.gmail.com>
 <8055b366-32f1-4d2c-85d0-0cf665e6c8d3@app.fastmail.com>
 <CAJpLVh2t5Y7CzYTJZxLViCYpgncuJg3i4v==q1gye1m-iR4QPQ@mail.gmail.com>
Date: Mon, 17 Jul 2023 19:57:32 +0000
To: =?UTF-8?Q?Olle_H=C3=A4rstedt?= <olleharstedt@gmail.com>
Cc: "Karoly Negyesi" <karoly@negyesi.net>,
 "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: larry@garfieldtech.com ("Larry Garfield")

On Mon, Jul 17, 2023, at 7:07 PM, Olle H=C3=A4rstedt wrote:
> 2023-07-17 18:58 GMT+02:00, Larry Garfield <larry@garfieldtech.com>:
>> On Mon, Jul 17, 2023, at 2:57 PM, Olle H=C3=A4rstedt wrote:
>>> 2023-07-17 14:25 GMT+02:00, Karoly Negyesi <karoly@negyesi.net>:
>>>> Hi,
>>>>
>>>> I tried to read on why the pipe RFC failed but by and large I also
>>>> failed.
>>>>
>>>> The discussion on https://github.com/php/php-src/pull/7214 is very
>>>> short.
>>>>
>>>> https://externals.io/message/114770 is not so short but it seems no=
t to
>>>> cover the latest version which uses first class functions?
>>>>
>>>> Could someone please give me a summary why it failed? I really would
>>>> like
>>>> to see it succeed :) I am writing code if not daily but certainly w=
eekly
>>>> that certainly looks like a pipeline.
>>>
>>> The pipe RFC was kinda forced in before a deadline, no?
>>>
>>> My own two cents:
>>>
>>> * It's trivial to implement a pipe() function or a Pipe class
>>> * A Pipe class is better than both a function and built-in operator,
>>> since it can be configured with custom behaviour, e.g. stop or throw
>>> on empty payload, or repeat on a collection, or even with parallelism
>>> or concurrency
>>> * If I had voting rights, I'd vote in favor in a pipe operator :)
>>
>> From my recollection, there were a couple of things involved.
>>
>> 1. It was intended to pair with the PFA RFC, which didn't pass, which=
 made
>> it a bit less compelling.
>> 2. It was close to the RFC deadline, and it seems people get squeamish
>> around that.
>> 3. Some folks wanted Hack-style pipes instead of the pipes used by ev=
ery
>> other language with pipes. I've written before on why that's a worse
>> design.
>> 4. Arguments that it can be done in user space, which is not true, as=
 I have
>> a user-space implementation and it's comparatively cumbersome and def=
initely
>> slower than a native operator would be.
>> 5. General "meh" attitude on FP features in general from some people.
>>
>> Side note to Olle: If you want a customizable pipe, you've just descr=
ibed a
>> Monad. :-)  It's literally "contextually-sensitive func concatenation=
."  A
>> monadic bind operator would be harder to do with PHP's weaker type sy=
stem,
>> but there are ways it could be done.
>
> Mm I don't really agree with that, I think monads make sense only in
> languages which support them syntactically. A Pipe class is a very
> straight-forward construction, and the blog posts I've read about
> monads in PHP don't look pretty at all; lots of syntactic noise going
> on. But that's another discussion... :)

At its most basic:

class Foo {
  public function __construct(public readonly mixed $val) {}

  public __bind(callable $c) {
    return $c($this->val);
  }
}

new Foo('beep') >>=3D func(...);

Where >>=3D is the operator that translates to "Call __bind() on the LHS=
 object with the callable on the RHS."  Poof, we now have a monad operat=
or.  This one is effectively the same as |> as it doesn't do anything, b=
ut you can do whatever you want in the __bind() method. =20

But that's a separate operation from |> or func concat.  (Unless we want=
ed to implement it as an operator override for |> that an object can do,=
 which... is an option.  I don't know if I like that option, but is an o=
ption.)

The implementation for all of this is fairly trivial.  It's agreeing to =
do it that is the challenge.

--Larry Garfield