Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115241
Date: Wed, 30 Jun 2021 15:59:01 +0200
To: "internals" <internals@lists.php.net>
Message-ID: <17a5d374765.1289062a2301127.8166821672739325531@limesurvey.org>
In-Reply-To: <CAJpLVh1yMvjEbVaOsj3n7QLEhgJpPuchq6Y4t33X_8ACOehU5g@mail.gmail.com>
References: <222b3921-3d9b-47f9-8d13-e6a123f36fad@www.fastmail.com>
 <CAC5V6ghFFjoP_JgUcJ14sFJ0DY-Q4z7qt40j9T5w0C3GHNsCrw@mail.gmail.com>
 <c16544c0-185a-43f9-853a-9941a018abe7@www.fastmail.com> <9f0c9565-22e1-4d94-bef5-cfc44ce02dc5@www.fastmail.com> <CAJpLVh1yMvjEbVaOsj3n7QLEhgJpPuchq6Y4t33X_8ACOehU5g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_1041287_1840044666.1625061541733"
Importance: Medium
User-Agent: Zoho Mail
Subject: [PHP-DEV] [Vote] Partial Function Application
From: olle.haerstedt@limesurvey.org (=?UTF-8?Q?Olle_H=C3=A4rstedt?=)

------=_Part_1041287_1840044666.1625061541733
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

https://github.com/LimeSurvey/LimeSurvey---- On Wed, 30 Jun 2021 14:22:46 +=
0200 Olle H=C3=A4rstedt <mailto:olleharstedt@gmail.com> wrote ----















---------- Forwarded message ---------
From: Larry Garfield <mailto:larry@garfieldtech.com>
Date: Tue, 29 Jun 2021, 20:05
Subject: Re: [PHP-DEV] [Vote] Partial Function Application
To: php internals <mailto:internals@lists.php.net>



On Tue, Jun 29, 2021, at 1:00 PM, Larry Garfield wrote:
 > On Tue, Jun 29, 2021, at 12:30 PM, Guilliam Xavier wrote:
 > > (Extracted from the "Pipe Operator, take 2" thread)
 > >=20
 > > On Tue, Jun 29, 2021 at 12:54 AM Larry Garfield <mailto:larry@garfield=
tech.com>
 > > wrote:
 > >=20
 > > > On Mon, Jun 28, 2021, at 5:30 PM, Olle H=C3=A4rstedt wrote:
 > > >
 > > > > Would a slimmed down version have more support? How about removing=
 the
 > > > > variadic operator, and let the user manually add the lambda for th=
ose
 > > > > cases?
 > > >
 > > > I talked with Joe about this, and the answer is no.=C2=A0 Most of th=
e
 > > > 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 inte=
racting
 > > > with the engine in a lot of different places.
 > > >
 > >=20
 > > Are you saying that the implementation complexity is mainly due to cho=
sing
 > > a syntax that looks like a function call?
 > > If yes, is it also the case for the "First-class callable syntax" RFC?
 > > And does it mean that a different syntax (e.g. with a prefix operator)
 > > would result in a simpler implementation?
 >=20
 > From what I understand from Joe, most of the complexity comes from=20
 > producing something that isn't a closure but shares the same interface=
=20
 > as a closure (at least that's what it would be in PHP terms), which=20
 > then requires lots of special handling throughout the engine.=C2=A0 I do=
n't=20
 > fully understand it all myself, TBH.
 >=20
 > I've been pondering if a completely different approach with a prefix=20
 > symbol would be able to be less complex, and the simple answer is I=20
 > have absolutely no idea.=C2=A0 But we are running low on symbols...
=20
 Ah, I found the technical details that Joe gave me (right after I hit send=
, of course).=C2=A0 Quoting Joe:
=20
 "the engine expects certain things to happen, and is designed and then opt=
imized around those assumptions ... for example, a stream of INIT, SEND, DO=
_FCALL is not meant to be interrupted, the first fundamental change you hav=
e to make is making the engine aware that stream of INIT, SEND, + are not a=
lways followed by DO_FCALL "
=20
 So yes, it sounds like hooking into the function call process is where the=
 complexity comes from.=C2=A0 Which suggests that an approach that works us=
ing a different syntax that desugars to a closure would avoid that issue, b=
ut then we need a syntax that wouldn't be ambiguous, and that's getting har=
der and harder to find.=C2=A0 (Nikita's first-class-callables RFC notes som=
e of the issues with available symbols, and they're essentially the same fo=
r partials either way.)=C2=A0 And I've been told that creating closures in =
the AST compiler is Hard(tm)...
=20
 --Larry Garfield






Wrapping stuff in lambdas is otherwise the obvious solution, no? Make `strl=
en(?)` evaluate to `fn ($x) =3D> strlen($x)`. Does it depend on the level o=
f look-ahead in the compiler why it's so hard? Didn't work much with script=
ing language internals.



Olle
------=_Part_1041287_1840044666.1625061541733--