Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93346
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.29 cause and error)
To: internals@lists.php.net
References: <CAESVnVpa5j=fagr-wm5+DzKKX=wzTN1p8+Kv3-KtGpuyH51b0A@mail.gmail.com>
 <CAESVnVr07J9UF3Dh7a1rMudMmQjeYuayvoT8Rmde+rfCBK6vnQ@mail.gmail.com>
 <452ddb93-1f47-1d0f-4f24-bedbff506b27@gmail.com>
 <CAESVnVqohR7rkaJASZ0rFuAD6GEiasqbAak-fJB3+K2vSKqHFQ@mail.gmail.com>
 <98.61.11104.A1D41375@pb1.pair.com>
 <7c94ca37-e188-dd2b-a66f-bb63bf03041a@gmail.com>
 <1463008795.1856219.605250569.74618FC4@webmail.messagingengine.com>
 <CANaX5nekRmhNKmY78tHRrev0_B3a-faRsQ8Jf=yA-jCkEP5-Ew@mail.gmail.com>
 <CAKrrN64bu+T0Sv4V6mo7i1cRYAh1W8Kx8tQ_rqQmZagXBTqKuQ@mail.gmail.com>
 <92E7F8A8-0845-48A7-91B1-9554C5F66C9D@zend.com>
 <CAESVnVq14EL_hJ=G_QTpvbzQhxP-Auy5p2rH9yja8bABsVr_sQ@mail.gmail.com>
 <879feadf-c04e-c0de-826b-110b3eb4e22f@php.net>
 <CAESVnVoW8+c1iDHxc52o2cxhiuBn7Z5Ag0+hsh1xKv73kUbBNQ@mail.gmail.com>
 <ff1cb37c-923b-f9c6-e326-c75a4f3e1623@php.net>
 <CAESVnVrn6iSZ7KWVDpcJ-Fw7k9NZnUbHUs88RBOBPsENg_sVWQ@mail.gmail.com>
 <85ec320c-b8d6-1cc8-2059-7b8dfa6589e2@php.net>
Message-ID: <5739237C.1090605@garfieldtech.com>
Date: Sun, 15 May 2016 20:33:48 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <85ec320c-b8d6-1cc8-2059-7b8dfa6589e2@php.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Pipe Operator
From: larry@garfieldtech.com (Larry Garfield)

On 05/14/2016 07:42 PM, François Laupretre wrote:
> Le 13/05/2016 à 20:16, Sara Golemon a écrit :
>>> for a potential solution to such a long-time issue as argument ordering
>>> sadness, IMHO, it's worth the pain. I am currently doing it and I'll 
>>> send
>>> you the list when it is ready.
>>>
>> Awesome.  Even if not used in this feature, it could potentially be
>> useful elsewhere.  I hope you put it in a public gist or similar for
>> posterity.
>
> After a quick check of every functions available in the PHP distrib, 
> only 55 functions should insert the lhs in a position different from 0 
> (first argument). From these 55 functions, 4 must not be used in a 
> pipeline and, for the remaining 51, the lhs must be inserted as 2nd, 
> 3rd, or 4th argument. The list and positions to use are available at :
>
> http://tekwire.net/joomla/projects/ideas/pipe-operator
>
> So, the logic would be :
>
> - if the function accepts 0 mandatory argument, it cannot be used in a 
> pipeline,
> - if the function is in the table referenced above, use the position 
> from the table,
> - else, insert the lhs as 1st arg.
>
> For internal functions, we can easily use some unused part of the 1st 
> arginfo element to store the position. The default will remain 0, 
> which doesn't require any change in current arginfo declarations. 
> We'll just have to define a new ZEND_BEGIN_ARG_INFO_xxx macro with an 
> explicit position. This macro will be used for the 55 functions 
> requiring a specific non-default position. -1 will be used to mark a 
> function as unusable in a pipeline.
>
> Once again, I think that argument ordering is a very important issue 
> and, here, we have an unique occasion to solve it for a rather 
> moderate price, since every functions have been audited.
>
> Another issue is caused by the sort functions returning the sorted 
> array by reference. The problem is the same with or without '$$'. In 
> practice, these functions cannot be used in a pipeline. So, either we 
> change their behavior to be different when used in a pipeline, which 
> is weird but allows an intuitive '|> sort() |>' notation, or we need 
> to define a new set of functions returning sorted arrays. None of 
> these is perfect but we'll have to propose a solution, as sorting is 
> essential when driving an array through a pipeline.
>
> Regards
>
> François

This still sounds awfully complicated to me.  I would far, far prefer 
the $$ syntax to special casing function aliases just to dance around 
it.  If we had a short-function syntax then requiring a piped function 
to have only a single argument would be both reasonable and 
typing-efficient.  Baring that, the $$ syntax seems far nicer than 
alternate versions of functions with implicit arguments but only in 
certain situations.

Side note: Please, people, use the Reply-List function in your email 
clients. I've gotten double-copies of everything in this thread since my 
last email. :-/

Also to Stas: Yes, I meant "continuation" earlier, not "concurrency"; 
brain fart on my part, as the latter clearly makes no sense at all in 
context.  In particular, I'm referring to Continuation-passing style:

https://en.wikipedia.org/wiki/Continuation-passing_style

Again, I think there's a lot of potential to this syntax, especially if 
we can find a way to make it forward-compatible with 
promises/async-await, or whatever we end up with in the async world.  
(Which... I suppose makes continuations a concurrency syntax after all, 
which may be why I brain farted on the C word I meant to type.)

--Larry Garfield