Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115199
Return-Path: <larry@garfieldtech.com>
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 46751 invoked from network); 28 Jun 2021 22:34:44 -0000
Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5)
  by pb1.pair.com with SMTP; 28 Jun 2021 22:34:44 -0000
Received: from php-smtp4.php.net (localhost [127.0.0.1])
	by php-smtp4.php.net (Postfix) with ESMTP id 574061804F3
	for <internals@lists.php.net>; Mon, 28 Jun 2021 15:54:36 -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.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,
	SPF_HELO_PASS,SPF_NONE autolearn=no autolearn_force=no version=3.4.2
X-Spam-Virus: No
X-Envelope-From: <larry@garfieldtech.com>
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(No client certificate requested)
	by php-smtp4.php.net (Postfix) with ESMTPS
	for <internals@lists.php.net>; Mon, 28 Jun 2021 15:54:35 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
	by mailout.west.internal (Postfix) with ESMTP id C78BA320090D
	for <internals@lists.php.net>; Mon, 28 Jun 2021 18:54:34 -0400 (EDT)
Received: from imap43 ([10.202.2.93])
  by compute1.internal (MEProxy); Mon, 28 Jun 2021 18:54:34 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=content-transfer-encoding:content-type
	:date:from:in-reply-to:message-id:mime-version:references
	:subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender
	:x-sasl-enc; s=fm3; bh=djjWh/eEDJeG+fOcF9Ju/LqbaMgwqs2GEf5MydtyD
	Nk=; b=HaIkXfE/a1CRwRYjKCaVRGYHCoQu0pfrNcj1zJ8oSwUV0fxg6c8ndY1sA
	ul4rZ4HfBexs0zESUonNBYs8R9gY+m9EzkgiLDKVkjWGPtCHRluPiynuv49PwSst
	7CKYyrzE2toOSgaKdinfA78GtIWbFGcGPapeT1j1NSZhN0Nj1dh1k5eLjWq3NHQZ
	66TrAoXp1vSD2dVyG2Ms8/6Z1aZYcLlz7EpAFhNbniuu+RQ73Z9bllDNniW0k41k
	3Qtgy1oMoUX/xipL35dd1eyUaGSJUs+ja1U2qiM0BFkt9e5fwq6pQM5/QNrunH8X
	JR762hgD3TGiQ2TAC0yqOeIvBL5Kw==
X-ME-Sender: <xms:KlPaYNAsBzvPd4I4Jo0eo_eCbb7Rq0p0rjs-bj61A1rF88LykZuhbQ>
    <xme:KlPaYLgQB4zS5-EdKdzOJ1Y3N_xhdRxF6bPFeOMbTLb17LoEHAAMqNjCtrwbN64UE
    1bRKDAdYlTv4A>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeehhedgudduucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
    uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
    cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfnfgr
    rhhrhicuifgrrhhfihgvlhgufdcuoehlrghrrhihsehgrghrfhhivghlughtvggthhdrtg
    homheqnecuggftrfgrthhtvghrnhepffffffejffdugfegvedviedttedvgfejffefffej
    leefjeetveehgefhhfdvgfelnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe
    hmrghilhhfrhhomheplhgrrhhrhiesghgrrhhfihgvlhguthgvtghhrdgtohhm
X-ME-Proxy: <xmx:KlPaYInGB-nhVZ-4pmrFx1c-l_ChqbNHpoJHFrk4leBLKFrHdeSrFw>
    <xmx:KlPaYHwK3k1i53qcMz3Iwj5gXDTdqRdEajVsHp5Hn_gj4SX7P1ho5w>
    <xmx:KlPaYCSjiRPDZksAjZbsxtXg4gx43ou07QECewXyL2re5DEeO_r19g>
    <xmx:KlPaYABhHw6p5MDRF2G-GNtHfoCQGAGYsN8Xi05MhsHtF394RTC43w>
Received: by mailuser.nyi.internal (Postfix, from userid 501)
	id 3749BAC0073; Mon, 28 Jun 2021 18:54:34 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-530-gd0c265785f-fm-20210616.002-gd0c26578
Mime-Version: 1.0
Message-ID: <13476e3c-93d6-4c6f-be9e-24f46a5049fb@www.fastmail.com>
In-Reply-To: 
 <CAJpLVh1JXStoumLrLTJwA7ouvgkkBoot6yu-7f=LeLC6G5spDQ@mail.gmail.com>
References: <d50eaa78-21c7-46e7-9da6-629ba5694d3f@www.fastmail.com>
 <CAJpLVh0Fo9odHeO_CoSxCKA+2dELhG7-H9BvY--tfd59q0iXhQ@mail.gmail.com>
 <b256ac45-e893-90b9-70ba-89fd326c1cf7@gmail.com>
 <43d612c0-7462-463a-9536-ed5b66d9ae1e@www.fastmail.com>
 <CAJpLVh1MUTi0b4HiHXEAfjeKvQXranwsdX9S8QagFYYEfn-9Jg@mail.gmail.com>
 <bd6cabb6-339a-46ca-8d50-f595f951ad58@www.fastmail.com>
 <CAJpLVh1JXStoumLrLTJwA7ouvgkkBoot6yu-7f=LeLC6G5spDQ@mail.gmail.com>
Date: Mon, 28 Jun 2021 17:54:14 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Pipe Operator, take 2
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Jun 28, 2021, at 5:30 PM, Olle H=C3=A4rstedt wrote:

> Mm. Assoc arrays are by now known to be not so good. I hope...

There are millions of PHP sites build on anonymous arrays today.

> OCaml is strictly evaluated, not lazy like Haskell. So the order might=

> matter, dunno, I don't use this operator often. :) My point was mostly=

> that it's very easy to add in OCaml - just one line. And as in
> Haskell, you can define operators in your modules. Similarly, in PHP
> it's easy to do super-dynamic stuff like "new $someclass", which is
> not remotely possible in FP (good or bad, depending on your religion).=

>=20
> Adding a new pipe keyword is like the list() keyword, kind of. A bad
> idea, haha. But I think all stones can be turned, if this RFC now gets=

> a no. :/
>=20
> Would a slimmed down version have more support? How about removing the=

> variadic operator, and let the user manually add the lambda for those
> cases? Could reduce the complexity while still covering maybe 80% of
> the use-cases? Same with removing support for named arguments. So '?'
> would only be a short-cut to get rid of boilerplate like `$strlen =3D
> fn($x) =3D> strlen($x)`.

I talked with Joe about this, and the answer is no.  Most of the complex=
ity comes from the initial "this is a function call, oops no, it's a par=
tial call so we switch to doing that instead", which ends up interacting=
 with the engine in a lot of different places.  Once you've done that, s=
upporting one placeholder or multiple, variadics or not, etc. is only a =
small incremental increase in complexity.

> > Overall, I really don't like the idea of special-casing pipes to cha=
nge what
> > symbol table gets looked up.
>=20
> Still wondering if this could be a per-file or per-library setting
> somehow, to opt-in into pipe behaviour when so desired. Or rather, to
> opt-in into this or that behaviour needed to do more idiomatic pipe.
>=20
> Here's one boilerplaty pipe:

*snip*

We're in the pipe thread here, not PFA. :-)  And really, you're solving =
the wrong problem.  Pipes are trivial.  They're only clunky because of P=
HP's lack of decent callable syntax.  PFA gives us that, but the engine =
makes the implementation more complex than it seems like at first glance=
.

Trying to come up with complex workarounds to make pipes pretty without =
helping anything else is a fool's errand, especially when we have a work=
ing PFA RFC that's about to end voting.  (And right now is losing by a v=
ery slim margin, but could pass if a few people change their minds.)

Aside from something like Nikita's ...-only function reference RFC, whic=
h only handles half the problem (it doesn't do anything to make multi-ar=
g functions work with pipes at all), any other solution is going to end =
up reinventing PFA one way or another, or reinventing existing ugly user=
-space libraries. one way or another

I've not yet decided if I'm going to bring pipes to a vote if PFA doesn'=
t pass.  I'm tempted to, but it would require rewriting all the RFC text=
 back to the uglier version without PFA, and yeah, it's not going to loo=
k as pretty.  And the main pushback a year ago when I first brought it u=
p was "PFA first, please, so the callable syntax isn't ugly."  And... he=
re we are.

--Larry Garfield