[PHP-DEV] Re: [RFC] Pre-draft for PipeOp v2
On 20.09.2017 at 00:32, Sara Golemon wrote:
> I was planning to update the RFC, but wiki.php.net is having issues
> atm and isn't coming back up with basic coaxing, so I'll just start
> discussion informally, and the RFC can be updates later.
>
> Background: I made an RFC some time ago to implement HackLang's Pipe
> Operator https://docs.hhvm.com/hack/operators/pipe-operator which
> provides fluent calling for non-object interfaces.
> I circulated it to mixed reviews, many negative, with the negativity
> feeling like it centered on the use of a magic placeholder token `$$`.
>
> After discussion with Levi and others who suggested a simpler
> approach, I'd like to offer
> https://github.com/php/php-src/compare/master...sgolemon:pipe2 as an
> alternate possibility.
>
> This version removes the $$ token, and instead treats the RHS of the
> expression as a callable obeying the same rules as the callable
> typehint elsewhere in the language. Specifically:
> * Free functions as strings containing the function name. (e.g. 'funcname')
> * Object methods as array($object, 'methodname')
> * Static methods as array('Classname', 'methodname')
> * Closure expression (e.g. function($x) { return ...; } )
> * Object instance with an __invoke() method.
>
> In a given pipe expression, the output of the LHS expression feeds a
> single arg to the callable on the RHS.
> Examples:
>
> $x = "hello"
> |> 'strtoupper'
> |> function($x) { return $x . " world"; };
> // $x === "HELLO world"
>
> Non-Goal: I didn't include support for base function names (e.g.
> `"hello" |> strtoupper`) because of the conflict with constants.
> Using a constant to store your function name is totes legit and
> consistent with language syntax.
I'm not particularly fond of a pipe(line) operator. I don't see a great
advantage over a simple compose function:
$appendWorld = function ($x) {return "$x world";};
$x = compose('strtoupper', $appendWorld)('hello');
The benefit of using a compose function would be the possibility of
point-free programming without explicitely declaring another function:
$toUpperAppendWorld = compose(
'strtoupper',
function ($x) {return "$x world";}
);
$x = $toUpperAppendWorld('hello');
$y = $toUpperAppendWorld('goodbye');
Basically, the compose function would be like the pipe operator without
special casing the (first) input.
See also Andreas's suggestion regarding built-in functions for common
functional primitives ().
--
Christoph M. Becker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Pre-draft for PipeOp v2
"Rowan Collins" wrote in message news:f9001e2a-8f13-d4ba-f514-f18dc1e4f...@gmail.com... On 28/09/2017 20:07, Levi Morrison wrote: The brace style is concise, nicely delimits the expression, and seems the clearest for me to read because the symbols don't dominate. This is something that I tried to push for in previous discussions - I've never liked the syntaxes where the expression floats away from the operator, and you have to work out where it ends. The counter-argument I got was that some people actually like writing things like this, although I'm not entirely clear why: fn($x) => fn($y) => in_array($x, $y) Just because some people would like to write code like this does not make it acceptable for the majority of the programming community. You should never forget that the primary aim of a programmer is to write code which can be read by a human, and only incidentally to be executed by a machine (H. Abelson and G. Sussman in "The Structure and Interpretation of Computer Programs", 1984). Some people complain that PHP is too verbose, so they strive to replace long words, or groups of words, with abbreviations or even symbols. This, IMHO, converts a readable program into a bunch of hieroglyphics and should therefore be avoided. I think there should be a rule which states that if something can already be done with 5 lines or less of userland code then it should not be built into the core language as it would be adding unnecessary complications that would only benefit a small minority of programmers but would be to the detriment of the majority. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Pre-draft for PipeOp v2
2017-09-28 21:07 GMT+02:00 Levi Morrison :
> On Wed, Sep 27, 2017 at 1:56 PM, Sara Golemon wrote:
>
> > On Thu, Sep 21, 2017 at 5:13 PM, Stanislav Malyshev >
> > wrote:
> > > It'd be also nice then if we could have some syntax that allowed us to
> > > refer to functions/methods as callables - mostly for the benefit of the
> > > code readers and IDEs. I.e. you can do "hello" |> "strtoupper" and it's
> > > fine but it is not at all intuitive what you're doing sending one
> string
> > > into another. Same with "hello" |> [$this, 'bar']. Now, if we could do
> > > something like this:
> > > "hello" |> &{strtoupper}
> > > "hello" |> &{$this->bar}
> > >
> > Super-hacky implementation (that I wouldn't want to merge, but it
> > shows the syntax at work).
> >
> > https://github.com/php/php-src/compare/master...sgolemon:lambda
> > which provides a form of both short-closures and partial functions.
> >
> > Combined with also-super-hacky pipe diff from earlier, you get:
> >
> > $x = "Hello"
> > |> &{strtoupper($0)}
> > |> &{ $0 . "world" }
> > |> &{strrev($0)};
> >
> > var_dump($x);
> > // string(10) "dlrowOLLEH"
> >
> > -Sara
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
> By the way the `&` is not required. When experimenting with possible short
> closure syntax I created an implementation for `{}` to make sure it was
> possible:
>
> $x = "Hello"
> |> {strtoupper($0)}
> |> { $0 . "world" }
> |> {strrev($0)};
>
> If people would prefer that syntax for short-closures then that's fine by
> me. If we made it this concise there wouldn't be a need for a `$$` proposal
> anyway.
>
I love this syntax with braces, I wanted to do like it in
https://wiki.php.net/rfc/short-closures
but only for replacement of string or array callables as closures.
>
> ---
>
> My impression from the community is that the pipe operator is desirable but
> not if it encourages string or array callables. In that vein which syntax
> do you prefer?
>
> // brace style
> $x = "Hello"
> |> {strtoupper($0)}
> |> { $0 . "world" }
> |> {strrev($0)};
>
> // fn style
> $x = "Hello"
> |> fn($x) => strtoupper($x)}
> |> fn($x) => $x . "world"
> |> fn($x) => strrev($0);
>
> // caret style
> $x = "Hello"
> |> ^($x) => strtoupper($x)}
> |> ^($x) => $x . "world"
> |> ^($x) => strrev($0);
>
> I included these two styles because they are the most promising versions
> from the arrow functions discussions. I think my preferred order is the one
> I wrote them in. The brace style is concise, nicely delimits the
> expression, and seems the clearest for me to read because the symbols don't
> dominate. The fn style seems nicer than caret which has too many symbols in
> close proximity for my taste.
>
> Community thoughts? Which short closure style pairs the nicest with the
> pipe operator?
>
--
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com
