Thank you all for your efforts, I think we're almost there and that PFA would be a really great and useful addition to the language.
Le jeu. 20 mai 2021 à 21:38, Larry Garfield <la...@garfieldtech.com> a écrit : > On Thu, May 20, 2021, at 10:55 AM, Guilliam Xavier wrote: > > On Thu, May 20, 2021 at 5:12 PM Nikita Popov <nikita....@gmail.com> > wrote: > > > > > On Thu, May 20, 2021 at 4:16 PM Ondřej Mirtes <ond...@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. > I've read that some ppl think this should be fought, but that's actually a critical feature of the engine when writing BC layers by adding extra arguments via this possibility. In the 2nd gist, I read "If the current position is a ..., copy all remaining parameters from the underlying function, including a variadic." But to me it's important that all extra arguments are forwarded to the partialized callable, where ... is used or not. Please clarify this point if possible. * 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. > For the userland pov, the principle of least surprise would say we should answer yes to both questions. > 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. > Then maybe named args should be forbidden for "?" placeholders. This would keep this possibility open of the future and close the "principle of least surprise" expectation if there are. Aka foo(bar: ?) should be a parse error for now at least. 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.) > I agree. Let's figure out PFAs! If I may add to the bikeshedding, and since PFAs are like others said "short lambas on steroids", what about borrowing the syntax from them? Here would be the first-class callable syntax: fn(...) => $callable(...) and for PFAs: fn(...) => $callable(?, 42, ...) Nicolas
