Re: [RFC] Pipe Operator, take 2

On Tue, Jun 8, 2021 at 4:09 PM Larry Garfield <larry@garfieldtech.com> wrote: > On Tue, Jun 8, 2021, at 5:41 AM, Guilliam Xavier wrote: > > > you forgot to update one > > explode(?) to > > str_split(?), and also, the first `fn($v) => > > 'strtoupper' should be just B ����� > > ��y�'strtoupper'`. > > I deliberately made that example extra verbose to show how ugly it can > get, but I can shorten it. > Extra verbose would have been fn($v) => strtoupper($v), there was obviously a typo (already correct in the second equivalent code fragment). Anyway, I see you fixed it, and also updated the Haskell section :thumbsup: > > > Also, quoting from > > > > https://wiki.php.net/rfc/first_class_callable_syntax#partial_function_application > > : > > > > """ > > Both approaches to the pipe operator have their advantages. The $$ based > > variant allows using more than plain function calls in each pipeline step > > (e.g. you could have $$->getName() as a step, something not possible with > > PFA), and is also trivially free. A PFA-based optimization would entail > > significant overhead relative to simple function calls, unless special > > optimization for the pipe operator usage is introduced (which may not be > > possible, depending on precise semantics). > > """ > > > > Could you (or Nikita) expand a bit on this (esp. the advantages of the > PFA > > approach / disadvantages of Hack's approach)? > > It's true PFA doesn't cover every possible RHS of pipes. In practice, I > think using the piped value as an object on which to invoke a method is the > only major gap. Normally in functional code you would use a lens in that > case, which (if I am understanding those correctly; that's roughly at the > edge of my functional understanding) is essentially a function call that > wraps accessing a property or calling a method so that it feels more > functional, and thus pipes cleanly. > > However, piping with callables has a number of advantages. > > 1) The implementation is vastly simpler. It's simple enough that even I > can manage it, whereas Hack-style would be more considerably implementation > work. > > 2) I would argue it's more flexible. Once you start thinking of > callables/functions in a first class way, producing functions on the fly > that do what you want becomes natural, and fits better with a > pipe-to-callable model. For instance, the comprehension-esque example > (which I suspect will be one of the most common use cases of pipes) is far > cleaner with a callable, as it can obviate any question about parameter > order. > > Another example I threw together last night is this proof of concept last > night, which works when pipes, enums, and partials are combined. I don't > think Hack-style would be capable of this, at least not as elegantly. > > https://gist.github.com/Crell/e484bb27372e7bc93516331a15069f97 > > (That's essentially a "naked either monad".) > > 3) I disagree that the overhead of arbitrary callables is "significant." > It's there, but at that point you're talking about optimizing function call > counts, mostly on partials; unless you're using pipes for absolutely > everything, go remove an SQL query or two and you'll get a bigger > performance boost. > > 4) Far more languages have callable pipes. Hack is, as far as I am aware, > entirely alone in having pipes be combined with a custom expression syntax > rather than just using functions/callables. That isn't conclusive proof of > anything, but it's certainly suggestive. > > I'm going to be moving forward with this approach one way or another (if > for point 1 if nothing else). I do believe it is the more flexible, more > robust approach, and fits with the general strategy I recommend of small, > targeted changes that combine with other small, targeted changes to offer > more functionality than either of them alone. That's exactly what we're > doing here. > All good points IMHO. Thanks! -- Guilliam Xavier