Re: pipes, scalar objects and on?
| From: | Larry Garfield | Date: | Wed, 19 Jul 2023 14:34:49 +0000 |
| Subject: | Re: pipes, scalar objects and on? | ||
| References: | 1 2 3 4 5 6 7 8 9 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-120850@lists.php.net to get a copy of this message | ||
On Wed, Jul 19, 2023, at 12:08 PM, Olle Härstedt 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ärstedt 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 simple
>>> 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 can 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, monads are the
mathematical rules that a "fancy function concatenation" operation has to follow in order
to still be composable cleanly. You could make pipeline-like things that don't follow those
rules, but they'd be less useful.)
Your logging example is literally the "writer monad," one of the standard monad examples.
--Larry Garfield