Re: [RFC] First-class callable syntax

On Thu, May 20, 2021, at 10:55 AM, Guilliam Xavier wrote: > On Thu, May 20, 2021 at 5:12 PM Nikita Popov <nikita.ppv@gmail.com> wrote: > > > On Thu, May 20, 2021 at 4:16 PM Ondřej Mirtes <ondrej@mirtes.cz> wrote: > > > > > Hi, I’m confused by the syntax, when I read it, I think to myself “I know > > > this, this is just a method call… oh wait, it’s actually a callable”. It > > > really makes my head hurt. > > > > > > > Yes, I can see how that could be confusing. The current syntax is chosen to > > be a subset of the partial function application proposal. However, I would > > also be happy with some other syntax that makes it clearer that this is > > acquiring a callable and not performing a call. > > > > Hi, several other syntaxes have been proposed to consideration in the PFA > thread, and I wouldn't want to start new bikeshedding here; is there a > place that would be more appropriate to gather the possibilities (like a > kind of updatable list)? > > Thanks, There's been a lot of rapid iteration, experimentation, and rejection. The most recent alternatives are this one from Levi: https://gist.github.com/morrisonlevi/f7cf949c02f5b9653048e9c52dd3cbfd And this one from me: https://gist.github.com/Crell/ead27e7319e41ba98b166aba89fcd7e8 The main takeaways (to give context to Nikita's proposal): * Because of optional arguments, using the same symbol for "copy one parameter from the underlying function" and "copy all remaining parameters from the underlying function" is not viable. It runs into oddball cases where you may intend to only use one argument but end up using multiple, especially in array operation functions that sometimes silently pass keys along to callbacks if they can. Hence the separate ? and ... that were proposed. * Named arguments make things more complicated. One of the questions is whether named placeholders should be supported or not. And if they are, does that mean you can effectively reorder the arguments in the partial application, and what does that mean for usability. It gets complicated and scope-creepy fast. * The most important use cases are: ** "prefill nothing, just give me a callable" (which is the case Nikita's RFC covers) ** "reduce an arbitrary function to a single remaining argument", which lets it be used by various existing callback functions in the standard library (array_map, array_filter, etc.), many user-space APIs, and the pipes RFC that I am planning to bring back up once PFA is figured out (https://wiki.php.net/rfc/pipe-operator-v2). While there are other use cases, the two of those cover the vast majority of uses. (There is some dispute about which of those is larger, or will be larger in the future.) It took a while to realize the first point, which basically killed "? means zero or more". We also went down a rabbit hole of trying to make argument reordering work because some people asked for it, but as noted that's a very deep rabbit hole. My gist above was a reduced-scope version of Levi's that uses two symbols and drops named placeholders. It doesn't give us every possible combination, but it does give us most reasonable combinations. Nikita's "just do the first one" RFC (this thread) was proposed at about the same time, and takes an even-further scope reduction. My own take is that the PFA discussion has been overly-bikeshedded, which is unfortunate since I think we're quite close to now having a workable answer that covers most reasonable use cases. While I agree Nikita's RFC here would be an improvement over 8.0, I don't think throwing in the towel on PFA yet is a good idea. It's a much more robust and powerful approach that still gets us the "first class callable" syntax we all want (at least I assume we all do), and lots of additional power to boot. I'd rather see us try to drive PFA home to completion. If that proves impossible by early July, then this RFC would still get us something this cycle, as long as the syntax is still compatible with PFA. (Otherwise whenever PFA gets sorted out in the future we end up with yet-more-ways to do the same thing that are not optimizations of each other but just competing syntax, in which case no one wins.) --Larry Garfield