Re: [RFC] Pipe Operator

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