Sorry for self-reply, this needs some clarifications :) Le ven. 21 mai 2021 à 09:17, Nicolas Grekas <nicolas.grekas+...@gmail.com> a écrit :
> 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. > I'm talking about implicit extra arguments accessed via func_get_args() here. 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. > Reading your gists, I'm with drawing this expectation. Since calls reorder named arguments automatically, we could expect the same for PFAs. That is: since foo(A: 1, B: 2) is exactly the same as foo(B: 2, A: 1) we could also expect that foo(A: ?, B: ?) would be exactly the same foo(B:?, A:?) The issue here is that the syntax can be interpreted as both a new signature and as a partial call. If we stay pure to the intend of PFAs, argument reordering shouldn't be allowed IMHO. Aka this should be interpreted only as a partial call. *If* we need a way to reorder arguments, I think it would be natural also to be able to *rename* arguments. That's where my syntax proposal based on short closures might be handy: fn($a, $b, ...) => $callable($b, a: $a, ...) > > >> 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 >
