On Mon, Jun 28, 2021, at 5:30 PM, Olle Härstedt wrote:

> Mm. Assoc arrays are by now known to be not so good. I hope...

There are millions of PHP sites build on anonymous arrays today.

> OCaml is strictly evaluated, not lazy like Haskell. So the order might
> matter, dunno, I don't use this operator often. :) My point was mostly
> that it's very easy to add in OCaml - just one line. And as in
> Haskell, you can define operators in your modules. Similarly, in PHP
> it's easy to do super-dynamic stuff like "new $someclass", which is
> not remotely possible in FP (good or bad, depending on your religion).
> 
> Adding a new pipe keyword is like the list() keyword, kind of. A bad
> idea, haha. But I think all stones can be turned, if this RFC now gets
> a no. :/
> 
> Would a slimmed down version have more support? How about removing the
> variadic operator, and let the user manually add the lambda for those
> cases? Could reduce the complexity while still covering maybe 80% of
> the use-cases? Same with removing support for named arguments. So '?'
> would only be a short-cut to get rid of boilerplate like `$strlen =
> fn($x) => strlen($x)`.

I talked with Joe about this, and the answer is no.  Most of the complexity 
comes from the initial "this is a function call, oops no, it's a partial call 
so we switch to doing that instead", which ends up interacting with the engine 
in a lot of different places.  Once you've done that, supporting one 
placeholder or multiple, variadics or not, etc. is only a small incremental 
increase in complexity.

> > Overall, I really don't like the idea of special-casing pipes to change what
> > symbol table gets looked up.
> 
> Still wondering if this could be a per-file or per-library setting
> somehow, to opt-in into pipe behaviour when so desired. Or rather, to
> opt-in into this or that behaviour needed to do more idiomatic pipe.
> 
> Here's one boilerplaty pipe:

*snip*

We're in the pipe thread here, not PFA. :-)  And really, you're solving the 
wrong problem.  Pipes are trivial.  They're only clunky because of PHP's lack 
of decent callable syntax.  PFA gives us that, but the engine makes the 
implementation more complex than it seems like at first glance.

Trying to come up with complex workarounds to make pipes pretty without helping 
anything else is a fool's errand, especially when we have a working PFA RFC 
that's about to end voting.  (And right now is losing by a very slim margin, 
but could pass if a few people change their minds.)

Aside from something like Nikita's ...-only function reference RFC, which only 
handles half the problem (it doesn't do anything to make multi-arg functions 
work with pipes at all), any other solution is going to end up reinventing PFA 
one way or another, or reinventing existing ugly user-space libraries. one way 
or another

I've not yet decided if I'm going to bring pipes to a vote if PFA doesn't pass. 
 I'm tempted to, but it would require rewriting all the RFC text back to the 
uglier version without PFA, and yeah, it's not going to look as pretty.  And 
the main pushback a year ago when I first brought it up was "PFA first, please, 
so the callable syntax isn't ugly."  And... here we are.

--Larry Garfield

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Reply via email to