Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:119694 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 16435 invoked from network); 14 Mar 2023 16:58:20 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 14 Mar 2023 16:58:20 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 3BCFD18050B for ; Tue, 14 Mar 2023 09:58:19 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS19151 66.111.4.0/24 X-Spam-Virus: No X-Envelope-From: Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 14 Mar 2023 09:58:18 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 40D8A5C08E6 for ; Tue, 14 Mar 2023 12:58:18 -0400 (EDT) Received: from imap50 ([10.202.2.100]) by compute4.internal (MEProxy); Tue, 14 Mar 2023 12:58:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= garfieldtech.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm2; t=1678813098; x=1678899498; bh=K5zYITDitH IjeoPZSeHWM8Zh9cY/DZc5ri2AAIWotiI=; b=l96PRmomdcia9TMEZZCqTEFglR wyE+1r/ozoti9QasKU4U3j97k9aGOO2wHcSU1ttEud3TEYKGFrFCyncU8vmcRsv1 9Ehjm25bW7r4LOvu7X3DnbIyo9L4Q5bFZp/d32dbZzqvxHwyvfMzgvgaO4paRMAW Z2sw0TerTyS2BThJFYlGU/boADO7+60jvhgvZDC/CuWJB3DpKFwqG2HAyRqCMfVy IH8+hHEgnzvIwgIIacucBGI/UMinDNdu86OOKBwPKRNYpVx1L/SP61rLtzaF6XvZ KJ0Xc19Cxhrdd/d1BiG/kbvIcP7K7WTqzxUsGNQH8zY1MrAM62zN1goEy8Hw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1678813098; x= 1678899498; bh=K5zYITDitHIjeoPZSeHWM8Zh9cY/DZc5ri2AAIWotiI=; b=I nsjU/pBqCPRR60A6ITapGLgXH7aTAE3rYKK7UE8nbGF4N9CJYVEiRKzt638X/hmj 1tS9ZRx4ys3xXVSbqfZaAdklctikqTwEQWoQAotMk9aIkdfeWnDME2Rxi8Qcfvla VQOj/aRZowPzt2fwujHs1zJ6/ilwsiaBX+FeFoeYJdosfxDe5k0KWk0XMaoNGl6Z Iy5D1h7ahutFODE9cuYpQmbrr/tMwd5aahvtFl49w7Vmz9qV621gQXMSJmI/CRdf tGbHoKIOH1twjYeiygqPT5T40Z185n/Ztm0VJR7IVvBGqM0CWdkwp/9KK4sxZjah Ep7+gNni5u1PHCkBIV3Bw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvddviedgleejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfnfgr rhhrhicuifgrrhhfihgvlhgufdcuoehlrghrrhihsehgrghrfhhivghlughtvggthhdrtg homheqnecuggftrfgrthhtvghrnhepffffffejffdugfegvedviedttedvgfejffefffej leefjeetveehgefhhfdvgfelnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomheplhgrrhhrhiesghgrrhhfihgvlhguthgvtghhrdgtohhm X-ME-Proxy: Feedback-ID: i8414410d:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id C2EBE1700089; Tue, 14 Mar 2023 12:58:17 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-221-gec32977366-fm-20230306.001-gec329773 Mime-Version: 1.0 Message-ID: <1a4d4434-7318-4831-9fc0-8b48a6400a62@app.fastmail.com> In-Reply-To: References: <9975B833-EE24-4ED7-B28E-841B92988BA0@cschneid.com> <1A2CE63B-ECCA-403D-83AC-B1E26279323C@gmail.com> <9a2140b4-97bb-4a9c-90c5-809274c83f75@app.fastmail.com> <88c4a63c-859b-94d5-e314-3399fb2c3fb0@gmail.com> Date: Tue, 14 Mar 2023 11:57:57 -0500 To: "php internals" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] First-class callable partial application From: larry@garfieldtech.com ("Larry Garfield") On Tue, Mar 14, 2023, at 8:50 AM, Robert Landers wrote: > On Tue, Mar 14, 2023 at 1:57=E2=80=AFPM Rowan Tommins wrote: >> >> On Tue, 14 Mar 2023 at 10:39, Bob Weinand wrote: >> >> > Hey Rowan, >> > >> > do we actually need *positional* partial application, after a ... t= oken? >> > >> > Would it not be enough, to simply forbid positional arguments after= a ... >> > and just allow named arguments? These already have well defined pos= ition >> > independent semantics. >> > >> > There may be some desire for a single argument placeholder later on= , but >> > this can be introduced later, separately. >> > >> >> >> Yes, named parameters would certainly be better than left-to-right on= ly. >> It's definitely less elegant, though, and given that PFA is largely >> short-hand for a short closure anyway, I think conciseness is quite an >> important aim. >> >> To take a couple of the above examples, and compare existing short cl= osure, >> fully positional PFA, and named-after-placeholder PFA: >> >> $isLogger =3D fn($object) =3D> is_subclass_of($object, LoggerInterfac= e::class, >> false); >> $isLogger =3D is_subclass_of(?, LoggerInterface::class, false); >> $isLogger =3D is_subclass_of(..., class: LoggerInterface::class, >> allow_string: false); >> >> $priceFormatter =3D fn(float $num) =3D> number_format($num, 2, ',', '= .'); >> $priceFormatter =3D number_format(?, 2, ',', '.'); >> $priceFormatter =3D number_format(..., decimals: 2, decimal_separator= : ',', >> thousands_separator: '.'); >> >> Arguably the named param version is more explicit, but in some cases = it's >> significantly longer than manually defining a closure, whereas fully >> positional PFA is always shorter. >> >> Regards, >> -- >> Rowan Tommins >> [IMSoP] > > Something I was partial to (pun slightly intended), when thinking > about it last summer was to put named parameters with dots following, > like this: > > $isLogger =3D is_subclass_of(object_or_class..., LoggerInterface::clas= s, false); > // or, since this is a beginning/end partial, this is the same: > $isLogger =3D is_subclass_of(..., LoggerInterface::class, false); > > $isLogger(object_or_class: $myClass); > // or > $isLogger($myClass); > > $priceFormatter =3D number_format(num..., 2, ',', '.'); > > At least, that was what I was going to propose, according to my notes. > Looking at it 8 months later, I still kinda like it. For reference, in the original RFC we had the following rules: ``` This RFC introduces two place holder symbols: The argument place holder ? means that exactly one argument is expec= ted at this position. The variadic place holder ... means that zero or more arguments may = be supplied at this position. The following rules apply to partial application: ... may only occur zero or one time ... may only be followed by named arguments named arguments must come after all place holders named placeholders are not supported ``` The reason for that was, I believe, because it was too complicated figur= e out the signature of the resulting closure if named placeholders were = allowed after the `...` . Optional arguments also got weird, IIRC. We = went around *a lot* on the details here before settling on the syntax we= did. I agree that requiring all partials to used named args would be a big st= ep down for usability. But again, none of this addresses the root issue that doomed the previou= s RFC: Any syntax that involves a runtime determination of "is this a fu= nction call or a partial application?" is going to involve some really t= ricky dancing along the critical path of all function calls. Even thoug= h Joe's implementation had no significant performance impact (AFAIR), it= still made the code more complex and potentially harder to optimize in = the future. So the only ways forward would be: 1) Find another approach in the implementation that doesn't have that pr= oblem, which may then changes to the proposed syntax and possibility cap= abilities. (I had suggested some prefix on the call to indicate that it= 's a partial and not a call, like %foo(1, ?, 3, ...) or something.) 2) The voter base shifts and/or changes its mind and decides that the ex= tra complexity is worth it. Redoing the syntax bikeshedding from 3 years ago (dear god, it's been 3 = years?) before one of those two is answered is not productive. New engi= ne approach first, then syntax based on what that approach allows. --Larry Garfield