On Mon, Jul 17, 2023, at 7:07 PM, Olle Härstedt wrote:
> 2023-07-17 18:58 GMT+02:00, Larry Garfield <la...@garfieldtech.com>:
>> On Mon, Jul 17, 2023, at 2:57 PM, Olle Härstedt wrote:
>>> 2023-07-17 14:25 GMT+02:00, Karoly Negyesi <kar...@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 not 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 weekly
>>>> 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 every
>> 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 definitely
>> 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 described a
>> Monad. :-) It's literally "contextually-sensitive func concatenation." A
>> monadic bind operator would be harder to do with PHP's weaker type system,
>> 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') >>= func(...);
Where >>= is the operator that translates to "Call __bind() on the LHS object
with the callable on the RHS." Poof, we now have a monad operator. This one
is effectively the same as |> as it doesn't do anything, but you can do
whatever you want in the __bind() method.
But that's a separate operation from |> or func concat. (Unless we wanted 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 option.)
The implementation for all of this is fairly trivial. It's agreeing to do it
that is the challenge.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
