Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120850
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-531-gfdfa13a06d-fm-20230703.001-gfdfa13a0
Mime-Version: 1.0
Message-ID: <64315dcc-9f78-4d8d-bc02-dfea5c725bda@app.fastmail.com>
In-Reply-To: 
 <CAJpLVh2T8tHpxwPB-O+qCNA7S32jtEy4F8U9n80wPeGjdQ_Drw@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>
 <CABAhh3FjjwyZjrpzrES6E1kbRz_czg64-CRxtKw-jkY5JzGYeA@mail.gmail.com>
 <CAJpLVh3BXQ4rB_5WZK7DopesFgwQ2K5xMD_EgWRQ0-Zd4BF_5A@mail.gmail.com>
 <51a97131-f64e-4939-9339-24e70873fe32@app.fastmail.com>
 <CAJpLVh0v9vGq2ytwWDzj9ogT_AUZiW0tptdGN5wuYV=hbSmDiQ@mail.gmail.com>
 <b1e37bc6-7ea8-4f34-8ae8-76a62bbd7694@app.fastmail.com>
 <CAJpLVh2T8tHpxwPB-O+qCNA7S32jtEy4F8U9n80wPeGjdQ_Drw@mail.gmail.com>
Date: Wed, 19 Jul 2023 14:34:49 +0000
To: =?UTF-8?Q?Olle_H=C3=A4rstedt?= <olleharstedt@gmail.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: larry@garfieldtech.com ("Larry Garfield")

On Wed, Jul 19, 2023, at 12:08 PM, Olle H=C3=A4rstedt wrote:
> 2023-07-18 18:50 GMT+02:00, Larry Garfield <larry@garfieldtech.com>:
>> On Tue, Jul 18, 2023, at 4:47 PM, Olle H=C3=A4rstedt wrote:
>>
>>> 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 simp=
le
>>> pipe operator. :) And also already possible with existing OOP
>>> concepts, callable classes, and now the (...) syntax.
>>
>> That's the function concat operator I have been mentioning.  Concat c=
an be
>> implemented in terms of pipe, and pipe can be implemented in terms of
>> concat, but I'd rather have both natively.
>>
>> For more on my thoughts there, see:
>> https://peakd.com/hive-168588/@crell/aoc2021-review
>
> Right, I think I was thinking more of the pipeline design pattern than
> the pipe operator. The concat operator will tell you THAT two
> functions have been glued together, but you have no way to affect HOW
> they are glued together. With the pipeline design pattern, you do: For
> example, you could add a logger that logs each input and output in the
> Pipe class without much hassle.
>
> The pipeline design pattern could still greatly benefit from some of
> these RFCs tho, especially partial function application, I think.
>
> Olle

OK, terminology mismatch.  What you're calling "pipeline design pattern"=
 I'm calling "that's literally what a monad is." :-)  (More precisely, m=
onads are the mathematical rules that a "fancy function concatenation" o=
peration has to follow in order to still be composable cleanly.  You cou=
ld make pipeline-like things that don't follow those rules, but they'd b=
e less useful.)

Your logging example is literally the "writer monad," one of the standar=
d monad examples.

--Larry Garfield