2023-07-17 21:57 GMT+02:00, Larry Garfield <la...@garfieldtech.com>: > 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.
1. You also want syntactic sugar around this to "flatten" monadic usage; in OCaml it's `let*`. 2. This way you won't get read-process-write pipelines as first-class values, which you can do if you just make a Pipe class instead. I think. Correct me if I'm wrong. :) Olle -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
