[RFC] [Discussion] Short Closures

Stas Malyshev

11 years ago

Hi!

> I had this RFC in draft since some time, but delayed it due to all
> the ongoing PHP 7 discussions. Also we have no master branch to merge
> features in until 5.4 EOL. Thus I'm reviving this now.
>
> Time for the first RFC targeting PHP 7.1 (assuming PHP 8 isn't going
> to be the next version ;-)):
>
> The short Closures RFC: https://wiki.php.net/rfc/short_closures

I personally don't see much advantage in making PHP code less readable
and harder to parse. Also, "automatically use () all of the (compiled)
variables" does not look like a good idea - first, users have no idea
what compiled variables are, so the result would be unpredictable for
them, second, if there are a lot of variables in the scope (like global
scope) it would have huge performance costs for no gain.
Also, this syntax does not allow "use by-ref" which the existing syntax
does allow.

I think we already have syntax for anonymous functions and it works. The
only addition in this RFC is automatically gobbling up all local
variables, which in vast majority of use cases is not what the function
needs.

--
Stas Malyshev
smalyshev@gmail.com

Nikita

11 years ago

On Tue, 01 Sep 2015 00:05:35 +0300, Stanislav Malyshev
<smalyshev@gmail.com> wrote:

> Hi!
>
>> I had this RFC in draft since some time, but delayed it due to all
>> the ongoing PHP 7 discussions. Also we have no master branch to merge
>> features in until 5.4 EOL. Thus I'm reviving this now.
>>
>> Time for the first RFC targeting PHP 7.1 (assuming PHP 8 isn't going
>> to be the next version ;-)):
>>
>> The short Closures RFC: https://wiki.php.net/rfc/short_closures
>
> I personally don't see much advantage in making PHP code less readable
> and harder to parse. Also, "automatically use () all of the (compiled)
> variables" does not look like a good idea - first, users have no idea
> what compiled variables are, so the result would be unpredictable for
> them, second, if there are a lot of variables in the scope (like global
> scope) it would have huge performance costs for no gain.
> Also, this syntax does not allow "use by-ref" which the existing syntax
> does allow.
>
> I think we already have syntax for anonymous functions and it works. The
> only addition in this RFC is automatically gobbling up all local
> variables, which in vast majority of use cases is not what the function
> needs.

Hi Stas,

Capture of all variables from the current scope is not the only addition
in this RFC. The main addition (which is extended by that btw) is making
the syntax shorter. Which, in turn, makes it easier to write and read
closures. I've had a huge lot of cases where I would benefit from it,
things like this:

$collection = array_filter(array_map(function (Type $el) { return
$el->getStuff(); }, $collection));

It would be much easier to read and write with the short syntax:

$collection = array_filter(array_map((Type $el) ~> $el->getStuff(),
$collection));

Just because, I'll say it, the less symbols you have to read the faster
you'll read it. To some extent, of course, a counter-example being Perl
language. But I don't think that we are even close to it.

Your point about capturing too much if you have too much in the global
scope is legit but in this case I'd say two things: you can still use long
closure syntax, and second you have a problem with global scope not short
closures.

You see the main use case for anon. functions is when you need a
*lightweight* callback for something. If it were a fat function I'd
probably make it named and write tests for it. But when it's a small
function, often consisting from only one expression it kinda bothers me
when the body of this function takes less keystrokes than 'function' and
'return' keywords...

Stas Malyshev

11 years ago

Hi!

> in this RFC. The main addition (which is extended by that btw) is making
> the syntax shorter. Which, in turn, makes it easier to write and read

Shrtr dsnt lwys mks thngs esr 2 rd.
Sometimes it's quite the opposite.

> It would be much easier to read and write with the short syntax:
>
>   $collection = array_filter(array_map((Type $el) ~> $el->getStuff(),
> $collection));

I disagree. It is very hard in this syntax so see where function call
starts and where it ends, especially if there are more that one
parameter and/or more than one closure.

> Just because, I'll say it, the less symbols you have to read the faster
> you'll read it. To some extent, of course, a counter-example being Perl
> language. But I don't think that we are even close to it.

Yes, in this instance we are. And that's not a good thing.

> Your point about capturing too much if you have too much in the global
> scope is legit but in this case I'd say two things: you can still use
> long closure syntax, and second you have a problem with global scope not
> short closures.

No, I don't have a problem with global scope - this proposal has a
problem with any scope that contains many variables. Actually, virtually
every scope contains more variables than closures need. Without this
capture there is no problem.

> You see the main use case for anon. functions is when you need a
> *lightweight* callback for something. If it were a fat function I'd

And capturing whole scope makes it anything but lightweight, especially
if you have big scope.

> probably make it named and write tests for it. But when it's a small
> function, often consisting from only one expression it kinda bothers me
> when the body of this function takes less keystrokes than 'function' and
> 'return' keywords...

If keystrokes are a problem, there are lots of solutions - like IDEs
that allow to define macros. Saving keystrokes at the cost of
readability never was a principle in PHP, and I don't think we should
start now.

--
Stas Malyshev
smalyshev@gmail.com

Bob Weinand

11 years ago

Hey, thanks for your feedback, but I think you'd got one or two things wrong…

> Am 01.09.2015 um 02:24 schrieb Stanislav Malyshev <smalyshev@gmail.com>:
>
> Hi!
>
>> in this RFC. The main addition (which is extended by that btw) is making
>> the syntax shorter. Which, in turn, makes it easier to write and read
>
> Shrtr dsnt lwys mks thngs esr 2 rd.
> Sometimes it's quite the opposite.
>
>> It would be much easier to read and write with the short syntax:
>>
>>  $collection = array_filter(array_map((Type $el) ~> $el->getStuff(),
>> $collection));
>
> I disagree. It is very hard in this syntax so see where function call
> starts and where it ends, especially if there are more that one
> parameter and/or more than one closure.

When I format my code weirdly, I'll have that issue too. Generally, if you have problems to read the code, if you'd write it with ~>, just use the classical function () use () {} syntax.
I'm not aiming at defacto abolishing the classical syntax (unlike [] which seems to have replaced array() everywhere in 5.4+ code...); in some contexts it's well readable (compared to ~>), especially, as you say, with three or more parameters.
The strong point of this RFC is quick callbacks (like a call to array_map), which just have one or two parameters. (Like shown in https://wiki.php.net/rfc/short_closures#extracting_data_from_an_array_and_summing_it)

Another big benefit is especially in more functional code, with partial applications. (Where you chain multiple closures)
I might be wrong, but I feel like the "clumsiness" of the classical syntax is especially harmful for that code and makes it harder to read (once you get a bit used to ~>, it will be easy to read, really).

>> Just because, I'll say it, the less symbols you have to read the faster
>> you'll read it. To some extent, of course, a counter-example being Perl
>> language. But I don't think that we are even close to it.
>
> Yes, in this instance we are. And that's not a good thing.

As said, there is a fine line between abusing the syntax and using it in horribly inapt scenarios, or using it where it really helps.

>> Your point about capturing too much if you have too much in the global
>> scope is legit but in this case I'd say two things: you can still use
>> long closure syntax, and second you have a problem with global scope not
>> short closures.
>
> No, I don't have a problem with global scope - this proposal has a
> problem with any scope that contains many variables. Actually, virtually
> every scope contains more variables than closures need. Without this
> capture there is no problem.
>
>> You see the main use case for anon. functions is when you need a
>> *lightweight* callback for something. If it were a fat function I'd
>
> And capturing whole scope makes it anything but lightweight, especially
> if you have big scope.

From the RFC:

> all variables used in the body of the anonymous function will automatically be bound to the anonymous function closure from the defining scope

The implementation is not capturing all the variables from the outer scope, but strictly only these accessed by the variables in the Closure itself. Hence that shouldn't be much of an issue.

>> probably make it named and write tests for it. But when it's a small
>> function, often consisting from only one expression it kinda bothers me
>> when the body of this function takes less keystrokes than 'function' and
>> 'return' keywords...
>
> If keystrokes are a problem, there are lots of solutions - like IDEs
> that allow to define macros. Saving keystrokes at the cost of
> readability never was a principle in PHP, and I don't think we should
> start now.

Agree, don't start with keystrokes here. They're maybe a nice side-effect, but that's really not a thing to argue about.
It's really not the goal of the RFC to decrease readability. That'd be insane.

> --
> Stas Malyshev
> smalyshev@gmail.com

Thanks,
Bob

Rasmus Lerdorf

11 years ago

> On Aug 31, 2015, at 18:04, Bob Weinand <bobwei9@hotmail.com> wrote:
>
> From the RFC:
>> all variables used in the body of the anonymous function will automatically be bound to the anonymous function closure from the defining scope
>
> The implementation is not capturing all the variables from the outer scope, but strictly only these accessed by the variables in the Closure itself. Hence that shouldn't be much of an issue.

This magic scares me. I made a very deliberate decision In the very first implementation of PHP to avoid scope side-effects like this. Inside a function everything is local unless explicitly declared not to be. This has carried through for the past 20+ years in slightly different ways, but the basic rule has stayed consistent even for closures. Unless explicitly declared via a use clause, every variable inside a closure is local and no cross-scope variable name side-effects are possible. I am not convinced that this feature is worth breaking that longstanding basic tenet of the language.

-Rasmus

Bob Weinand

11 years ago

> Am 01.09.2015 um 04:55 schrieb Rasmus Lerdorf <rasmus@lerdorf.com>:
>
>> On Aug 31, 2015, at 18:04, Bob Weinand <bobwei9@hotmail.com> wrote:
>>
>> From the RFC:
>>> all variables used in the body of the anonymous function will automatically be bound to the anonymous function closure from the defining scope
>>
>> The implementation is not capturing all the variables from the outer scope, but strictly only these accessed by the variables in the Closure itself. Hence that shouldn't be much of an issue.
>
> This magic scares me. I made a very deliberate decision In the very first implementation of PHP to avoid scope side-effects like this. Inside a function everything is local unless explicitly declared not to be. This has carried through for the past 20+ years in slightly different ways, but the basic rule has stayed consistent even for closures. Unless explicitly declared via a use clause, every variable inside a closure is local and no cross-scope variable name side-effects are possible. I am not convinced that this feature is worth breaking that longstanding basic tenet of the language.
>
> -Rasmus

I'd like to note that it's binding by value and not by reference nor true closing over.
There are no side effects, only importing of the variables.

Also, as stated, an important application is quick closures to be passed to e.g. array_map:

/* increment by $y */
$y = 10;
$array = array_map($x ~> $x + $y, $array);

Here it is very obvious that we want to import a variable. Especially, I wonder how
$array = array_map(function ($x) use ($y) { return $x + $y; }, $array);
is making such simple applications more readable? And especially, what value does it add here?

If you want to be scoping-safe, (e.g. in bigger Closures inside a large function), there always is the explicit syntax allowing you to do that.
Short Closures are a tool for certain use cases, not a swiss knife.

Bob

P.s.: Just a side-question ... Why did you then think, it's be a great idea for include/require to share scope?

Stas Malyshev

11 years ago

Hi!

> Here it is very obvious that we want to import a variable. Especially, I wonder how
> $array = array_map(function ($x) use ($y) { return $x + $y; }, $array);
> is making such simple applications more readable? And especially, what value does it add here?

It is making it more readable by explicitly specifying that we're using
function, that this function imports $y from parent scope and returns $x
+ $y. Of course, a seasoned programmer that has years of experience in
functional languages would recognize this pattern, but that's not
exactly the main target audience of PHP.

And I do not think the argument "you don't have to use it" is a good one
for adding language syntax constructs. If it's in the language, you'd
have to deal with it, and you'd have to teach other people to deal with
it. It's not some function sitting in the extension that may not even be
loaded - it's part of language syntax. So if it would encourage
write-only code, you'd have to deal with it even if you don't personally
create write-only code.

--
Stas Malyshev
smalyshev@gmail.com

Anthony Ferrara

11 years ago

Stas,

On Mon, Aug 31, 2015 at 11:46 PM, Stanislav Malyshev
<smalyshev@gmail.com> wrote:

> Hi!
>
>> Here it is very obvious that we want to import a variable. Especially, I wonder how
>> $array = array_map(function ($x) use ($y) { return $x + $y; }, $array);
>> is making such simple applications more readable? And especially, what value does it add here?
>
> It is making it more readable by explicitly specifying that we're using
> function, that this function imports $y from parent scope and returns $x
> + $y. Of course, a seasoned programmer that has years of experience in
> functional languages would recognize this pattern, but that's not
> exactly the main target audience of PHP.

I think that's quite a bit hyperbolic of an argument.

Most programming languages today have a "short form" closure or lambda syntax

HackLang: ($x) ==> $x + 1;
C++: [](int x) -> int { return x + 1; }
Java: (int x) -> x + 1;
Python: lambda x: x+1
Ruby: lambda |x| { x + 1 }
Rust: |x| x + 1
JavaScript (ES6): x => x + 1
C#: x => x + 1
Objective C: ^(int x) { return x + 1; }

Note that not a single one of those is a "functional" language. That's
every language in the top 10 index except PERL, PHP and VB.NET (though
VB has a similar syntax: function (x as Integer) x + 1),

I agree that at first it will feel a little bit weird, especially
given that PHP in general lacks syntactic sugar (we still don't have a
short-hand to initialize stdclass objects). We introduced [] back in
5.4, and largely it has made readability FAR better (despite some
people saying it wouldn't at the time).

> And I do not think the argument "you don't have to use it" is a good one
> for adding language syntax constructs. If it's in the language, you'd
> have to deal with it, and you'd have to teach other people to deal with
> it. It's not some function sitting in the extension that may not even be
> loaded - it's part of language syntax. So if it would encourage
> write-only code, you'd have to deal with it even if you don't personally
> create write-only code.

I agree 100%. "you don't have to use it" sucks as an argument. However
I don't think that's what Bob meant. He was trying to convey that the
tool isn't always appropriate in all situations. You can craft code
that makes this new syntax look unreadable. But you can craft code
that makes this look far more readable.

Example:

function partial(callable $cb) {
return function($left) use ($cb) {
return function($right) use ($cb, $left) {
return $cb($left, $right);
};
};
}

vs:

function partial(callable $cb) {
return $left ~> $right ~> $cb($left, $right);
}

It may look weird at first, but consider that's because you're not
used to the syntax. To me, the top is far harder to follow because of
the shear number of tokens to follow, not to mention that I need to
pay attention to the use-blocks which may or may not be importing
certain variables. The bottom reads exactly how I would expect it to.

Both are completely explicit in what they do and how they behave.

That's my opinion anyway...

Anthony

Stas Malyshev

11 years ago

Hi!

> I agree that at first it will feel a little bit weird, especially
> given that PHP in general lacks syntactic sugar (we still don't have a
> short-hand to initialize stdclass objects). We introduced [] back in
> 5.4, and largely it has made readability FAR better (despite some
> people saying it wouldn't at the time).

That doesn't mean now we have to drop all keywords and switch to
write-only style. Even [] was somewhat controversial, though it is the
most elementary syntax construct. Function call is in no way elementary
- it has non-trivial structure, and obscuring this structure by removing
keywords does not help readability.

> tool isn't always appropriate in all situations. You can craft code
> that makes this new syntax look unreadable. But you can craft code

The problem is not that I can. The problem is that anybody can, and a
lot of people would, unwittingly, once the expressions get more complex
that $x+1.

> that makes this look far more readable.
>
> Example:
>
> function partial(callable $cb) {
>     return function($left) use ($cb) {
>         return function($right) use ($cb, $left) {
>             return $cb($left, $right);
>         };
>     };
> }

It is a bit verbose but pretty clear what's going on here - function
returns a function that returns a function, and you can easily track
which variable goes where and how it gets to the end.

>
> vs:
>
> function partial(callable $cb) {
>     return $left ~> $right ~> $cb($left, $right);
> }

It looks very pretty as the ASCII art, and no entry-level programmer
would have any idea at all what these arrows actually do and how this
thing is supposed to work. At least not without studying the manual very
closely for extended time. That's exactly the problem. People start
writing overly clever code that looks so pretty - and then other people
are left scratching their heads about what actually is happening there.
That's what I mean by write-only code.

> It may look weird at first, but consider that's because you're not
> used to the syntax. To me, the top is far harder to follow because of

Of course, with enough training you can get fluent even in APL. I know
people that are. But PHP is supposed to be on the other end of the
spectrum.

> the shear number of tokens to follow, not to mention that I need to
> pay attention to the use-blocks which may or may not be importing
> certain variables. The bottom reads exactly how I would expect it to.

That's because you wrote it and know in advance what it is supposed to
do. It's not a good test of readability.

--
Stas Malyshev
smalyshev@gmail.com

Yasuo Ohgaki

11 years ago

Hi Anthony and Bob,

On Tue, Sep 1, 2015 at 2:53 PM, Anthony Ferrara <ircmaxell@gmail.com> wrote:

> Most programming languages today have a "short form" closure or lambda syntax
>
> HackLang: ($x) ==> $x + 1;
> C++: [](int x) -> int { return x + 1; }
> Java: (int x) -> x + 1;
> Python: lambda x: x+1
> Ruby: lambda |x| { x + 1 }
> Rust: |x| x + 1
> JavaScript (ES6): x => x + 1
> C#: x => x + 1
> Objective C: ^(int x) { return x + 1; }

Nice summary!
The syntax may look strange at first, but proposed syntax is close enough to
other languages. There will be no barrier for our users in the long run.

I thought scope variables enabled by default is destructive at first,
but Bob clarify
they are passed by value. Therefore, it would not be issue.

Bob, is there reason not to use the same syntax as Hack "==>"?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Rowan Collins

11 years ago

Anthony Ferrara wrote on 01/09/2015 06:53:

> function partial(callable $cb) {
>      return $left ~> $right ~> $cb($left, $right);
> }

The thing that is most unreadable to me in this is the associativity.
Someone from, say, a Haskell background might be used to mentally
grouping X -> Y -> Z into a series of steps but to an untrained eye it
looks almost like there's a list of terms with ~> as the separator. As I
understand it, an expanded form would be:

return ($left) ~> { return ($right) ~> { return $cb($left, $right) } };

...which is a bit easier to mentally group, but not much prettier than
current PHP syntax.

What about something a bit more "enclosed" but still short. A
for-loop-style construct occured to me:

# lambda(params; expression)
lambda($a, $b; $a * $b)
lambda($x; { while(foo()) { $x ++; } return $x; })

The curly braces don't look very natural in that last example, but I'm
not sure what else to use. Maybe just use the existing function() syntax
if you want a block rather than an expression?

A nice expansion of this would be to have an explicit use clause without
any extra keywords:

# lambda(params; bound vars; expression)
$double = lambda($a;; 2*$a)
$x=3; $triple = lambda($a; $x; $x * $a)

Taking one of the RFC's examples:

function sumEventScores($events, $scores) {
$types = array_map(lambda($event;; $event['type']), $events);
return array_reduce($types, lambda($sum, $type; $scores; $sum +
$scores[$type]));
}


The next example benefits less if we allow only expressions, but you
could still write this:

function reduce(callable $fn) {
return lambda($initial; $fn;
function($input) use ($fn, $initial) {
$accumulator = $initial;
foreach ($input as $value) {
$accumulator = $fn($accumulator, $value);
}
return $accumulator;
}
);
}


I'll leave it to others to judge if this is better or worse than the
current proposal, just playing with ideas...

Regards,
Rowan Collins

--
[IMSoP]

Ferenc Kovacs

11 years ago

2015. aug. 31. 21:29 ezt írta ("Bob Weinand" <bobwei9@hotmail.com>):

>
> I had this RFC in draft since some time, but delayed it due to all the

ongoing PHP 7 discussions. Also we have no master branch to merge features
in until 5.4 EOL. Thus I'm reviving this now.

>
> Time for the first RFC targeting PHP 7.1 (assuming PHP 8 isn't going to

be the next version ;-)):

>
> The short Closures RFC:
> https://wiki.php.net/rfc/short_closures
>
> Hoping for constructive feedback,
> Bob
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

+1 for having short closure operator, -1 for autocopying everything from
the current scope.

Pavel Kouřil

11 years ago

On Mon, Aug 31, 2015 at 9:29 PM, Bob Weinand <bobwei9@hotmail.com> wrote:

> I had this RFC in draft since some time, but delayed it due to all the ongoing PHP 7 discussions. Also we have no master branch to merge features in until 5.4 EOL. Thus I'm reviving this now.
>
> Time for the first RFC targeting PHP 7.1 (assuming PHP 8 isn't going to be the next version ;-)):
>
> The short Closures RFC:
> https://wiki.php.net/rfc/short_closures
>
> Hoping for constructive feedback,
> Bob
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Hi,

as a purely userland developer, I would definitely appreciate the
shorthand function for anonymous functions; having tons of stuff like
"function ($x) { return $x * 2; }"  makes the code less readable in
the end.

I'm not sure about the "auto using" of all variables though; wouldnt
it be possible to statically check for the used variables and only
import what's needed, for performance reasons?

Also, how hard would it be to add type hints (only for parameters)?
Sometimes they are needed to make the IDE know the variable type
because it can't be guessed automatically. I know about your note in
RFC,this is just a question to other internal members.Return type can
be infered by IDEs from the simple expresion quite easily.

PS: would "() ~> foo()" work? I think it should, but I couldn't find a
mention about it in RFC. :)

Regards
Pavel Kouril

Anthony Ferrara

11 years ago

Pavel

On Tue, Sep 1, 2015 at 4:32 AM, Pavel Kouřil <pajousek@gmail.com> wrote:

> On Mon, Aug 31, 2015 at 9:29 PM, Bob Weinand <bobwei9@hotmail.com> wrote:
>> I had this RFC in draft since some time, but delayed it due to all the ongoing PHP 7 discussions. Also we have no master branch to merge features in until 5.4 EOL. Thus I'm reviving this now.
>>
>> Time for the first RFC targeting PHP 7.1 (assuming PHP 8 isn't going to be the next version ;-)):
>>
>> The short Closures RFC:
>> https://wiki.php.net/rfc/short_closures
>>
>> Hoping for constructive feedback,
>> Bob
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
> Hi,
>
> as a purely userland developer, I would definitely appreciate the
> shorthand function for anonymous functions; having tons of stuff like
> "function ($x) { return $x * 2; }"  makes the code less readable in
> the end.
>
> I'm not sure about the "auto using" of all variables though; wouldnt
> it be possible to statically check for the used variables and only
> import what's needed, for performance reasons?

That's precisely what's happening. Not all variables are bound, only
those that are used. Somehow somewhere in this thread the confusion
was implied that the entire scope is copied.

> Also, how hard would it be to add type hints (only for parameters)?
> Sometimes they are needed to make the IDE know the variable type
> because it can't be guessed automatically. I know about your note in
> RFC,this is just a question to other internal members.Return type can
> be infered by IDEs from the simple expresion quite easily.
>
> PS: would "() ~> foo()" work? I think it should, but I couldn't find a
> mention about it in RFC. :)

Typing on closures is outside the scope of this RFC.

With that said, I'd love to hear and see examples of this. It's
something I definitely want to do, just haven't come up with a good
enough way to do it...

Anthony

Pavel Kouřil

11 years ago

On Tue, Sep 1, 2015 at 10:44 AM, Anthony Ferrara <ircmaxell@gmail.com> wrote:

>> I'm not sure about the "auto using" of all variables though; wouldnt
>> it be possible to statically check for the used variables and only
>> import what's needed, for performance reasons?
>
> That's precisely what's happening. Not all variables are bound, only
> those that are used. Somehow somewhere in this thread the confusion
> was implied that the entire scope is copied.
>

Oh, nice - thanks for explaining that. :)

>> Also, how hard would it be to add type hints (only for parameters)?
>> Sometimes they are needed to make the IDE know the variable type
>> because it can't be guessed automatically. I know about your note in
>> RFC,this is just a question to other internal members.Return type can
>> be infered by IDEs from the simple expresion quite easily.
>>
>> PS: would "() ~> foo()" work? I think it should, but I couldn't find a
>> mention about it in RFC. :)
>
> Typing on closures is outside the scope of this RFC.
>
> With that said, I'd love to hear and see examples of this. It's
> something I definitely want to do, just haven't come up with a good
> enough way to do it...
>

Yeah, I know it's outside of the scope of the RFC, it was more of a
general question whether or not it would be possible in the future.
Also, exactly what examples would you want to see?

Pavel

Kingsquare.nl - Robin Speekenbrink

11 years ago

Dear all,

Just to throw in my 2 cents as a userland developer: having multiple
ways to write the same thing isnt always right, but does have
advantages. (i.e. the [] shorthand is gaining alot of popularity as
already noted) (and might even force array() into deprecation imho)

But it does also add clutter since a developer has to have _more_
syntax knowledge in order to read the code. In this case, chaining
alot of short hand closures would require a bit of a learning curve
where the function() syntax is already everywhere... Reading the
functions is more self-explanatory...

But anyway, with regard to the type hints and such: I saw the [draft]
Callable-types RFC ( https://wiki.php.net/rfc/callable-types ) which
before this discussion really sparked my interest of having types
_everywhere_ (yeeeey!) and with this shorthand closure RFC the two
might even get all the FP guys back into PHP ;)

In anycase, Anthony, you might want to have a look at the draft RFC,
since from a userland view, this seems a really good way to go.

Good luck with this development people! Looking forward to whatever
comes out of it!
Met vriendelijke groet,

Robin Speekenbrink
Kingsquare BV


2015-09-01 10:44 GMT+02:00 Anthony Ferrara <ircmaxell@gmail.com>:

Derick Rethans

11 years ago

On Mon, 31 Aug 2015, Bob Weinand wrote:

> I had this RFC in draft since some time, but delayed it due to all the ongoing PHP 7 discussions. Also we have no master branch to merge features in until 5.4 EOL. Thus I'm reviving this now.
>
> Time for the first RFC targeting PHP 7.1 (assuming PHP 8 isn't going to be the next version ;-)):
>
> The short Closures RFC:
> https://wiki.php.net/rfc/short_closures

The RFC writes:

> The symbol ~> was chosen as it is a mnemonic device to help
> programmers understand that the variable is being brought to a
> function.

I don't see how this is a mnemonic. I am also struggeling seeing the
difference between -> and ~> in certain fonts.

> Currently Hack has implemented shorthand anonymous functions using the
> ==> symbol to define them.

> Additionally, ==> in Hack has slightly different semantics, hence we
> decided, it's better to not reuse that symbol

What are the difference in semantics?
Why not just copy the Hack semantics (and hence, then also use it's symbol)?

cheers,
Derick

Thomas Punt

11 years ago

Hi Bob,

> I had this RFC in draft since some time, but delayed it due to all the ongoing PHP 7 discussions. Also we have no master branch to merge features in until 5.4 EOL. Thus I'm reviving this now.
>
> Time for the first RFC targeting PHP 7.1 (assuming PHP 8 isn't going to be the next version ;-)):
>
> The short Closures RFC:
> https://wiki.php.net/rfc/short_closures
>
> Hoping for constructive feedback,
> Bob

Whilst I'd like to see a more expressive syntax for closures (and many other
things) in PHP, I'm personally -1 on your proposal. The feature feels too
inconsistent with the syntax and semantics of current PHP constructs for the
following reasons:
1) The automatic binding of variables from the outer scope to the inner scope.
2) The optional use of parentheses for parameter definitions, but only when a
single argument is used.
3) The optional use of braces for the function body, but only when a single
expression is used.
4) The automatic returning of the expression, but only when it is alone, and
only if the braces are omitted.

These four differences create further special cases for people to learn and
have no precedence in the language at all. They seem more like Rubyisms than
PHPisms.

Whilst we're on the topic of a terser syntax for closures though, Elixir has an
even shorter syntax:
&(&1 + &2)

The &() denotes an closure definition; the &N is used to create placeholders,
where N corresponds to the argument number. The ampersand obviously cannot be
reused for this in PHP, but the dollar sign could:
$func = $($1 + $2);
var_dump($func(3, 4)); // int(7)

This syntax should only be used in trivial scenarios, though, and comes with
the disadvantage of no type information.

Thanks,
Tom

Sara Golemon

10 years ago

On Mon, Aug 31, 2015 at 12:29 PM, Bob Weinand <bobwei9@hotmail.com> wrote:

> The short Closures RFC:
> https://wiki.php.net/rfc/short_closures
>

I just want to toss in my two cents as someone who's been using short
closures on a PHPish platform for some time already, because
predictions are one thing, experience in another.

The first time I saw "==>" I was like "what the eff?", but then you
know what I did? I looked up what it did, and I haven't had a problem
reading it since.  In fact, I have a much easier time reading a short
lambda than an over verbose function declaration sitting in the middle
of another expression.

I don't think PHP needs to adopt every feature that the majority of
the most used languages have chosen to implement, but this one should
really be a no-brainer, regardless of which token is used.  Because
code-beauty does matter.  Beautiful code is code that is easier to
maintain, and code that is easier to maintain is often more secure and
reliable.

That's all.

-Sara

Rowan Collins

10 years ago

On 02/09/2015 22:49, Sara Golemon wrote:

> Beautiful code is code that is easier to
> maintain, and code that is easier to maintain is often more secure and
> reliable.

I think this is an important point. Obviously, "beauty" is subjective:
some people will find very verbose, English-like code easier to read;
others might try to squeeze as much information into one screenful as
possible, so they can see the whole program at a glance.

At one extreme, SQL has mandatory words like the "AS" in "CAST(x AS
int)" just to "look more like English"; at the other, APL has symbols
all of its own with their own Unicode code points. Most languages aim
for some compromise in between.


So I would like to put forward for consideration these amendments to the
proposal, in the spirit of compromise (in no particular order; numbers
are just for reference in future discussion):

Amendment 1. Only allow the single-expression form of the short syntax;
full function bodies must be declared with the existing function(){ ...
} syntax. This gives a clearer distinction between how the two syntaxes
can be used.

Amendment 2. Make the ~> operator non-associative, so that lambdas
returning lambdas would need an extra pair of brackets making the
nesting explicit. To take one of Anthony's examples:

function partial(callable $cb) {
return $left ~> ( $right ~> $cb($left, $right) );
}

It's now at least clearer that there are two different anonymous functions here, even if it's not entirely clear what they're trying to achieve...

Amendment 3. Make the parentheses around the argument list mandatory so
that (if Amendment 1 is also adopted) there is only a single variant of
the syntax, namely "( param list ) ~> expression".

Amendment 4. Consider a syntax involving an explicit "use". This one
requires a bit more exploration, but maybe something like:
( $a use $b ) ~> $a + $b
or:
( $a ) use ( $b ) ~> $a + $b


Perhaps there are other thoughts along these lines that could move the
proposal beyond a simple love/hate debate.

Regards,

--
Rowan Collins
[IMSoP]

Pavel Kouřil

10 years ago

On Thu, Sep 3, 2015 at 12:48 AM, Rowan Collins <rowan.collins@gmail.com> wrote:

>
> So I would like to put forward for consideration these amendments to the
> proposal, in the spirit of compromise (in no particular order; numbers are
> just for reference in future discussion):
>
> Amendment 1. Only allow the single-expression form of the short syntax; full
> function bodies must be declared with the existing function(){ ... } syntax.
> This gives a clearer distinction between how the two syntaxes can be used.

This one sounds reasonable, but you'll probably get a RFC for almost
every upcoming version to allow the more complex bodies.

> Amendment 2. Make the ~> operator non-associative, so that lambdas returning
> lambdas would need an extra pair of brackets making the nesting explicit. To
> take one of Anthony's examples:
>
> function partial(callable $cb) {
>     return $left ~> ( $right ~> $cb($left, $right) );
> }
>
> It's now at least clearer that there are two different anonymous functions
> here, even if it's not entirely clear what they're trying to achieve...
>

Why? Once you read documentation about how the operator works and what
it does, you will know it and writing the extra brackets seems
superfluos. And woudn't this complicate the parser even more? Also, if
you have no idea about functional programming whatsoever, this will be
hard to grasp in any syntax form, but the syntax isn't the problem in
that case (as I already said in previous email).

> Amendment 3. Make the parentheses around the argument list mandatory so that
> (if Amendment 1 is also adopted) there is only a single variant of the
> syntax, namely "( param list ) ~> expression".
>
>
> Amendment 4. Consider a syntax involving an explicit "use". This one
> requires a bit more exploration, but maybe something like:
> ( $a use $b ) ~> $a + $b
> or:
> ( $a ) use ( $b ) ~> $a + $b
>

So you are taking a syntax that's supposed to be short and "clean" and
making it more complex by the amedments 3 and 4? I wouldn't mind the
mandatory ( ) around parameters, but at the same time I think that
it's an useless rule and makes the written code more "cluttered" (too
much ( and ) imho make the code less readable).


Btw. about your previous email and this syntax ending your career -
why would it? Reading the documentation and doing a mental note of
"simplified anonymous function declaration with optional ( ) if
there's just one paramater and automatically returning the expression
or having a whole function body enclosed in { }" shouldn't be a
problem? This is definitely not a "write-only" code.

If you are afraid the syntax will make the code less readable - look
at other languages (not for the sake of "they do it too", but for "how
does the code using it look like"). I can only speak about C#, and it
feels like it fits there - even though the language has more verbose
constructs and stuff. This should IMHO be a natural fit for PHP.

Regards
Pavel Kouril

Rowan Collins

10 years ago

Pavel Kouřil wrote on 03/09/2015 07:32:

> Amendment 2. Make the ~> operator non-associative

> Why? Once you read documentation about how the operator works and what
> it does, you will know it and writing the extra brackets seems
> superfluos. And woudn't this complicate the parser even more? Also, if
> you have no idea about functional programming whatsoever, this will be
> hard to grasp in any syntax form, but the syntax isn't the problem in
> that case (as I already said in previous email).

Yeah, maybe this one is just me - I just find right-associativity really
hard to read, whatever it's purpose. Maybe it's because I've only ever
read left-to-right languages.

As mentioned in a previous e-mail, when I look at "$a ~> $b ~> $c" it
makes me think of a single chain where all the terms are somehow
related, like "$a = $b = $c", rather than any kind of nesting. Maybe I'd
get used to it, maybe it would be rare enough that I'd never need to.

> So you are taking a syntax that's supposed to be short and "clean" and
> making it more complex by the amedments 3 and 4?

No, I'm trying to think of compromises which address constructive
criticisms people have made of the current proposal, such as the variety
of syntax forms, and the implicit scoping of variables.

To be clear, these are not demands or anything like that, just
suggestions of how to move the discussion beyond "here's the proposal,
take it or leave it".

> Btw. about your previous email and this syntax ending your career -
> why would it?

That wasn't my e-mail, it was one I replied to. I'm not against this
proposal, I'm genuinely trying to find ways forward with it.

Regards,

--
Rowan Collins
[IMSoP]

Björn Larsson

10 years ago

Den 2015-09-03 kl. 11:56, skrev Rowan Collins:

> Pavel Kouřil wrote on 03/09/2015 07:32:
>> Amendment 2. Make the ~> operator non-associative
>
>> Why? Once you read documentation about how the operator works and what
>> it does, you will know it and writing the extra brackets seems
>> superfluos. And woudn't this complicate the parser even more? Also, if
>> you have no idea about functional programming whatsoever, this will be
>> hard to grasp in any syntax form, but the syntax isn't the problem in
>> that case (as I already said in previous email).
>
> Yeah, maybe this one is just me - I just find right-associativity
> really hard to read, whatever it's purpose. Maybe it's because I've
> only ever read left-to-right languages.
>
> As mentioned in a previous e-mail, when I look at "$a ~> $b ~> $c" it
> makes me think of a single chain where all the terms are somehow
> related, like "$a = $b = $c", rather than any kind of nesting. Maybe
> I'd get used to it, maybe it would be rare enough that I'd never need to.
>
>
>> So you are taking a syntax that's supposed to be short and "clean" and
>> making it more complex by the amedments 3 and 4?
>
> No, I'm trying to think of compromises which address constructive
> criticisms people have made of the current proposal, such as the
> variety of syntax forms, and the implicit scoping of variables.
>
> To be clear, these are not demands or anything like that, just
> suggestions of how to move the discussion beyond "here's the proposal,
> take it or leave it".

Really appreciate that! Like the idea but the variation in syntax forms
is a bit confusing. Maybe one start with a very simple function and as
as you expand it the syntax form needs to change which I think is a
drawback.

Regards , //Björn Larsson

Pavel Kouřil

10 years ago

On Thu, Sep 3, 2015 at 11:56 AM, Rowan Collins <rowan.collins@gmail.com> wrote:

> Pavel Kouřil wrote on 03/09/2015 07:32:
>>
>> Amendment 2. Make the ~> operator non-associative
>
>
>> Why? Once you read documentation about how the operator works and what
>> it does, you will know it and writing the extra brackets seems
>> superfluos. And woudn't this complicate the parser even more? Also, if
>> you have no idea about functional programming whatsoever, this will be
>> hard to grasp in any syntax form, but the syntax isn't the problem in
>> that case (as I already said in previous email).
>
>
> Yeah, maybe this one is just me - I just find right-associativity really
> hard to read, whatever it's purpose. Maybe it's because I've only ever read
> left-to-right languages.
>
> As mentioned in a previous e-mail, when I look at "$a ~> $b ~> $c" it makes
> me think of a single chain where all the terms are somehow related, like "$a
> = $b = $c", rather than any kind of nesting. Maybe I'd get used to it, maybe
> it would be rare enough that I'd never need to.

Yeah, my guess is that most developers would use this just for more
simple array_map/array_filter/etc. usage, so you probably wouldn't
encounter this use case "in the wild" much.

But imagine having something like this (combined with your #3):

function partial($cb) { return ($left) ~> (($right) ~> $cb($left, $right)); }

I hope I got the parenthesination correct, because now there's a ton
of parenthesis and it's even harder to read (and write). If I had to
choose between amendments #3 and #2, I'd go with #3 just for the sake
of consistency - but I definitely wouldn't choose both of them
simultaneously.

But even just #3 seems kinda "harder" to read than the form without
any parenthesis.

function partial($cb) { return ($left) ~> ($right) ~> $cb($left, $right); }

I know the parenthesis are optional in just one scenario, but I'd
argue it's probably the most common one.

>> So you are taking a syntax that's supposed to be short and "clean" and
>> making it more complex by the amedments 3 and 4?
>
>
> No, I'm trying to think of compromises which address constructive criticisms
> people have made of the current proposal, such as the variety of syntax
> forms, and the implicit scoping of variables.
>
> To be clear, these are not demands or anything like that, just suggestions
> of how to move the discussion beyond "here's the proposal, take it or leave
> it".
>

Yes, I hope everyone is trying to move the discussion forwards,
because I would love to see this in some reasonable form in PHP.

In my personal order of "most reasonable" ammendments, it would be #1

> #3 > #2 > #4. The #1 I could even see getting positive feedback,

because for everything longer than one statement, people can use the
function () { ... } declaration (unlike in some other languages).

>
>> Btw. about your previous email and this syntax ending your career -
>> why would it?
>
>
> That wasn't my e-mail, it was one I replied to. I'm not against this
> proposal, I'm genuinely trying to find ways forward with it.
>

Oh, really sorry! I read a lot of those emails at the same time and
somehow got two emails mixed up together! :)


Regards
PK

Peter Lind

10 years ago

On 4 September 2015 at 08:44, Pavel Kouřil <pajousek@gmail.com> wrote:

*snip*

> But even just #3 seems kinda "harder" to read than the form without
> any parenthesis.
>
> function partial($cb) { return ($left) ~> ($right) ~> $cb($left, $right); }
>
> I know the parenthesis are optional in just one scenario, but I'd
> argue it's probably the most common one.
>

You're arguing that, subjectively, to you - parentheses make things harder
to read. For others they clarify things.
It should be obvious to everyone that this particular path of the
discussion has about as much merit as tabs vs spaces.

That being the case, I would argue for consistency and simplicity. If you
need parentheses for other variants of this, require parentheses all the
way through. It will be simpler to learn and trip fewer people up.

Just think, if whoever constructed the if conditional hadnt thought "hey,
let's be clever and save some keystrokes by making the curlies optional in
some cases" we wouldn't have the multitude of bugs and security holes we
know to exist, we wouldn't have to warn the young'uns against improper use
of if, we wouldn't have to write codesniffer rules against single line ifs,
etc, etc.

Any argument to the effect of "let's be clever" or "it'll save some
keystrokes" is void. Period.

Regards
Peter

--
<hype>
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
</hype>

Pavel Kouřil

10 years ago

On Fri, Sep 4, 2015 at 8:57 AM, Peter Lind <peter.e.lind@gmail.com> wrote:

> On 4 September 2015 at 08:44, Pavel Kouřil <pajousek@gmail.com> wrote:
>
> You're arguing that, subjectively, to you - parentheses make things harder
> to read. For others they clarify things.
> It should be obvious to everyone that this particular path of the discussion
> has about as much merit as tabs vs spaces.

Sure, it is subjective - but what isn't?

> That being the case, I would argue for consistency and simplicity. If you
> need parentheses for other variants of this, require parentheses all the way
> through. It will be simpler to learn and trip fewer people up.

Depends how you define simplicity. Because $a ~> $b ~> $c ~> $d is
IMHO more simple than ($a) ~> ((($b) ~> (($c) ~> $d($foo))) - which is
a result of the combination of amendments #2 and #3. I honestly do not
know if I wrote the parenthesis right now or not (probably not),
because there's simply just too many of them.

Sure, parenthesis can help people understand things, but I'd say that
at the same time, too many of them can be a problem as well (as the
fun name for LISP - "lost in stupid parenthesis" - suggests).

> Just think, if whoever constructed the if conditional hadnt thought "hey,
> let's be clever and save some keystrokes by making the curlies optional in
> some cases" we wouldn't have the multitude of bugs and security holes we
> know to exist, we wouldn't have to warn the young'uns against improper use
> of if, we wouldn't have to write codesniffer rules against single line ifs,
> etc, etc.
>
> Any argument to the effect of "let's be clever" or "it'll save some
> keystrokes" is void. Period.

This is not about saving characters, it's about not overcomplicating things.

>
> Regards
> Peter
>

Regards
PK

Peter Lind

10 years ago

On 4 September 2015 at 09:43, Pavel Kouřil <pajousek@gmail.com> wrote:

> On Fri, Sep 4, 2015 at 8:57 AM, Peter Lind <peter.e.lind@gmail.com> wrote:
> > On 4 September 2015 at 08:44, Pavel Kouřil <pajousek@gmail.com> wrote:
> >
> > You're arguing that, subjectively, to you - parentheses make things
> harder
> > to read. For others they clarify things.
> > It should be obvious to everyone that this particular path of the
> discussion
> > has about as much merit as tabs vs spaces.
>
> Sure, it is subjective - but what isn't?
>
>

Consistency isn't.

> > That being the case, I would argue for consistency and simplicity. If you
> > need parentheses for other variants of this, require parentheses all the
> way
> > through. It will be simpler to learn and trip fewer people up.
>
> Depends how you define simplicity. Because $a ~> $b ~> $c ~> $d is
> IMHO more simple than ($a) ~> ((($b) ~> (($c) ~> $d($foo))) - which is
> a result of the combination of amendments #2 and #3. I honestly do not
> know if I wrote the parenthesis right now or not (probably not),
> because there's simply just too many of them.
>
> Sure, parenthesis can help people understand things, but I'd say that
> at the same time, too many of them can be a problem as well (as the
> fun name for LISP - "lost in stupid parenthesis" - suggests).
>
>

Is it? And are the examples you make use of the only two options?
What about requiring parentheses around arguments, but not around the
function body? That would guard against stupid "I'll add another argument
... why isn't it working?!?!?!" errors (getting a syntax error and then
having to fix your code isn't easier than just consistently adding
parentheses around arguments).

> > Just think, if whoever constructed the if conditional hadnt thought "hey,
> > let's be clever and save some keystrokes by making the curlies optional
> in
> > some cases" we wouldn't have the multitude of bugs and security holes we
> > know to exist, we wouldn't have to warn the young'uns against improper
> use
> > of if, we wouldn't have to write codesniffer rules against single line
> ifs,
> > etc, etc.
> >
> > Any argument to the effect of "let's be clever" or "it'll save some
> > keystrokes" is void. Period.
>
> This is not about saving characters, it's about not overcomplicating
> things.
>

You're aiming for the "let's be clever" camp, far as I can tell.

--
<hype>
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
</hype>

Daniel Persson

10 years ago

> Depends how you define simplicity. Because $a ~> $b ~> $c ~> $d is
> IMHO more simple than ($a) ~> ((($b) ~> (($c) ~> $d($foo))) - which is
> a result of the combination of amendments #2 and #3. I honestly do not
> know if I wrote the parenthesis right now or not (probably not),
> because there's simply just too many of them.

Might be a good place to suggest refactoring?
Removing a semantics because when you try to write too dense code it's hard
to read.
The same goes with an one line if assignments.

$a = ( [some really big expression] ) ? $b : $c;

Could be really hard to read but then you look into refactoring that code.

Might be my inexperience with closures but when do you chain 3 of them?

Best regards
Daniel


On Fri, Sep 4, 2015 at 9:43 AM, Pavel Kouřil <pajousek@gmail.com> wrote:

Levi Morrison

10 years ago

(This post is fairly lengthy so I have copied it into a gist if you
would prefer to read it that way:
https://gist.github.com/morrisonlevi/8323125182ca3b5e2124)

Here's a practical example of chaining closures together that allows
us to easily implement versions of `array_map` and `array_reduce` that
are highly generic, meaning they can be used with various kinds of
input and output types instead of just arrays. These new versions can
also easily be chained together to form a "pipe" of transformations.
While the short-form closures are not required for this to work it
does make it much simpler.

Also, I know this is a fair bit of code to dump at once; it's really
hard to give meaningful examples that don't have some length to them.
Please don't skip this code!

$map = $fn ~> $input ~> {
foreach ($input as $key => $value) {
yield $key => $fn($value);
}
};

$reduce = $initial ~> $fn ~> $input ~> {
$accumulator = $initial;
foreach ($input as $value) {
$accumulator = $fn($accumulator, $value);
}
return $accumulator;
};

// this is just a helper function
// can skip reading it if you want
function chain(callable $fn, callable ...$callables) {
$functions = func_get_args();
return (...$params) ~> {
$count = count($functions);
$carry = $functions[0](...$params);
for ($i = 1; $i < $count; $i++) {
$carry = $functions[$i]($carry);
}
return $carry;
};
}

This essentially allows for binding only certain parameters and
chaining whole algorithms together:

$algorithm = chain(
$map($x ~> $x * 2),
$reduce([])(function ($accumulator, $value) {
$accumulator[] = $value;
return $accumulator;
})
);

$result = $algorithm($iterable);

Note that while I've used a basic array here for brevity I could have
used any kind of container that supports adding single items. For
instance, I could have used a set:

$set = new Set();
$algorithm = chain(
$map($x ~> $x * 2),
$reduce($set)(function ($set, $value) {
$set->add($value)
return $set;
})
);

$result = $algorithm($iterable);

Now all the duplicates get removed should there be any.

-----

Hopefully I've been able to demonstrate that this style of coding is
powerful and that the chaining of closures was helpful. Here are the
long-form closure equivalents for contrast:

$map = function ($fn) {
return function($input) use($fn) {
foreach ($input as $key => $value) {
yield $key => $fn($value);
}
};
};

$reduce = function ($initial) {
return function ($fn) use($initial) {
return function($input) use($initial, $fn) {
$accumulator = $initial;
foreach ($input as $value) {
$accumulator = $fn($accumulator, $value);
}
return $accumulator;
};
};
};

function chain(callable $fn, callable ...$callables) {
$functions = func_get_args();
return function(...$params) use($functions) {
$count = count($functions);
$carry = $functions[0](...$params);
for ($i = 1; $i < $count; $i++) {
$carry = $functions[$i]($carry);
}
return $carry;
};
}

$algorithm = chain(
$map(function ($x) {
return $x * 2;
}),
$reduce([])(function ($accumulator, $value) {
$accumulator[] = $value;
return $accumulator;
})
);

----

Some people have also suggested removing the block syntax for short
closures. The implementation of reduce as defined above is a
demonstration of why the block syntax is helpful:

$reduce = $initial ~> $fn ~> $input ~> {
$accumulator = $initial;
foreach ($input as $value) {
$accumulator = $fn($accumulator, $value);
}
return $accumulator;
};

With the block syntax removed the last closure in the chain has to use
long-form like this:

$reduce = $initial ~> $fn ~> function($input) use($initial, $fn) {
$accumulator = $initial;
foreach ($input as $value) {
$accumulator = $fn($accumulator, $value);
}
return $accumulator;
};

I hope you'll agree with me that this is just weird. I was initially
against the block syntax but after using it in meaningful code I
concluded that the block syntax is helpful.

Rowan Collins

10 years ago

Pavel Kouřil wrote on 03/09/2015 07:32:

> I wouldn't mind the
> mandatory ( ) around parameters, but at the same time I think that
> it's an useless rule and makes the written code more "cluttered" (too
> much ( and ) imho make the code less readable).

Bear in mind that under the current proposal, the parentheses are only
optional in the special case of a closure with exactly one parameter.
Any time you want zero parameters, or more than one, you have to put
them in anyway.

Sara Golemon

10 years ago

On Wed, Sep 2, 2015 at 3:48 PM, Rowan Collins <rowan.collins@gmail.com> wrote:

> Amendment 1. Only allow the single-expression form of the short syntax; full
> function bodies must be declared with the existing function(){ ... } syntax.
> This gives a clearer distinction between how the two syntaxes can be used.
>

I'm down with that.  Short syntax works best when it's concise.  If my
callback needs to do more, I tend to prefer writing the method
elsewhere, and naming the variable its in according to what it does.
Yay readability!

> Amendment 2. Make the ~> operator non-associative, so that lambdas returning
> lambdas would need an extra pair of brackets making the nesting explicit. To
> take one of Anthony's examples:
>
> function partial(callable $cb) {
>     return $left ~> ( $right ~> $cb($left, $right) );
> }
>
> It's now at least clearer that there are two different anonymous functions
> here, even if it's not entirely clear what they're trying to achieve...
>

Again, I support this.  I use parenthesis generously so that there's
never a doubt.  And because we got ternary's associativity wrong.

> Amendment 3. Make the parentheses around the argument list mandatory so that
> (if Amendment 1 is also adopted) there is only a single variant of the
> syntax, namely "( param list ) ~> expression".
>

I like it for consistency, but I will say that 80% of my short lambda
uses are callbacks for map and filter, which are single arg callbacks
(when used without keys), so I do seldom see parens used at all.... in
fact, I think that just convinced me why we need to be consistent.
Imagine someone not understanding why adding a second parameter breaks
their short lamba declaration...

> Amendment 4. Consider a syntax involving an explicit "use". This one
> requires a bit more exploration, but maybe something like:
> ( $a use $b ) ~> $a + $b
> or:
> ( $a ) use ( $b ) ~> $a + $b
>

Not a fan of this one at all.  Maybe it's my Javascript showing
through, but I like the automatic capture.  Not that I'd cry foul if
it were required though.  Good short lambdas are short short lambdas,
so their use statements would be small anyway.

-Sara

Björn Larsson

10 years ago

Den 2015-09-03 kl. 00:48, skrev Rowan Collins:

> On 02/09/2015 22:49, Sara Golemon wrote:
>> Beautiful code is code that is easier to
>> maintain, and code that is easier to maintain is often more secure and
>> reliable.
>
> I think this is an important point. Obviously, "beauty" is subjective:
> some people will find very verbose, English-like code easier to read;
> others might try to squeeze as much information into one screenful as
> possible, so they can see the whole program at a glance.
>
> At one extreme, SQL has mandatory words like the "AS" in "CAST(x AS
> int)" just to "look more like English"; at the other, APL has symbols
> all of its own with their own Unicode code points. Most languages aim
> for some compromise in between.
>
>
> So I would like to put forward for consideration these amendments to
> the proposal, in the spirit of compromise (in no particular order;
> numbers are just for reference in future discussion):
>
> Amendment 1. Only allow the single-expression form of the short
> syntax; full function bodies must be declared with the existing
> function(){ ... } syntax. This gives a clearer distinction between how
> the two syntaxes can be used.
>
> Amendment 2. Make the ~> operator non-associative, so that lambdas
> returning lambdas would need an extra pair of brackets making the
> nesting explicit. To take one of Anthony's examples:
>
> function partial(callable $cb) {
>     return $left ~> ( $right ~> $cb($left, $right) );
> }
>
> It's now at least clearer that there are two different anonymous
> functions here, even if it's not entirely clear what they're trying to
> achieve...
>
> Amendment 3. Make the parentheses around the argument list mandatory
> so that (if Amendment 1 is also adopted) there is only a single
> variant of the syntax, namely "( param list ) ~> expression".
>
> Amendment 4. Consider a syntax involving an explicit "use". This one
> requires a bit more exploration, but maybe something like:
> ( $a use $b ) ~> $a + $b
> or:
> ( $a ) use ( $b ) ~> $a + $b
>
>
> Perhaps there are other thoughts along these lines that could move the
> proposal beyond a simple love/hate debate.
>
> Regards,
>

Any plans to incorporate any of the amendments above in the RFC?
Personally I favour amendment 3. One of your examples would be:
functionreduce(callable $fn){
return($initial)~>($input)~>{
$accumulator=$initial;
foreach($inputas$value){
$accumulator=$fn($accumulator,$value);
}
return$accumulator;};
}

Or maybe I'm just overly familiar having function arguments
within parenthesis ;)

Regards, //Björn Larsson

Bob Weinand

10 years ago

> Am 10.09.2015 um 22:04 schrieb Björn Larsson <bjorn.x.larsson@telia.com>:
>
> Den 2015-09-03 kl. 00:48, skrev Rowan Collins:
>> Amendment 3. Make the parentheses around the argument list mandatory so that (if Amendment 1 is also adopted) there is only a single variant of the syntax, namely "( param list ) ~> expression".
>>
> Any plans to incorporate any of the amendments above in the RFC?
> Personally I favour amendment 3. One of your examples would be:
> functionreduce(callable $fn){
> return($initial)~>($input)~>{
>    $accumulator=$initial;
>        foreach($inputas$value){
>            $accumulator=$fn($accumulator,$value);
>        }
>    return$accumulator;};
> }
>
> Or maybe I'm just overly familiar having function arguments
> within parenthesis ;)
>
> Regards, //Björn Larsson

You are probably just very familiar with them ;-)

It totally isn't unusual to have that (for languages allowing untyped params), see:
Javascript (ES6)
Hack
C#

(There probably are more, I just can recall these three off my head)

So, I think this very much falls under personal preference.

Bob

Björn Larsson

10 years ago

Den 2015-09-10 kl. 22:22, skrev Bob Weinand:

>> Am 10.09.2015 um 22:04 schrieb Björn Larsson <bjorn.x.larsson@telia.com>:
>>
>> Den 2015-09-03 kl. 00:48, skrev Rowan Collins:
>>> Amendment 3. Make the parentheses around the argument list mandatory so that (if Amendment 1 is also adopted) there is only a single variant of the syntax, namely "( param list ) ~> expression".
>>>
>> Any plans to incorporate any of the amendments above in the RFC?
>> Personally I favour amendment 3. One of your examples would be:
>> functionreduce(callable $fn){
>> return($initial)~>($input)~>{
>>     $accumulator=$initial;
>>         foreach($inputas$value){
>>             $accumulator=$fn($accumulator,$value);
>>         }
>>     return$accumulator;};
>> }
>>
>> Or maybe I'm just overly familiar having function arguments
>> within parenthesis ;)
>>
>> Regards, //Björn Larsson
> You are probably just very familiar with them ;-)
>
> It totally isn't unusual to have that (for languages allowing untyped params), see:
> Javascript (ES6)
> Hack
> C#
>
> (There probably are more, I just can recall these three off my head)
>
> So, I think this very much falls under personal preference.
>
> Bob

Yes, for me it's about not needing to think whether parenthesis
should be there or not. So one more thing to not think about...

Anyway, I noticed that both C# and Hack uses lamda functions for
asynchronous programming, so good to get going with this RFC!
Hack example:
|async (int $x, string $y): Awaitable<Foo> ==> await $x->genFoo($y, $z);

//Björn

|

Dan

10 years ago

>
> I had this RFC in draft since some time, but delayed it due to all the
> ongoing PHP 7 discussions. Also we have no master branch to merge features
> in until 5.4 EOL. Thus I'm reviving this now.
>
> Time for the first RFC targeting PHP 7.1 (assuming PHP 8 isn't going to be
> the next version ;-)):
>
> The short Closures RFC:
> https://wiki.php.net/rfc/short_closures
>
> Hoping for constructive feedback,
> Bob
>

As a PHP developer (not an internals developer) - I love this proposal!

Out of interest, is there a technical reason you couldn't use an existing
token, such as => for this? If you could, it'd be almost identical to the
syntax used in C#:

*ThingList.Where(x => x > 7)*
*PersonList.Where(p => (p.Gender == "M" && p.Age < 30))*

Dan

Rowan Collins

10 years ago

Dan Cryer wrote on 03/09/2015 11:40:

> Out of interest, is there a technical reason you couldn't use an existing
> token, such as => for this?

https://wiki.php.net/rfc/short_closures#symbol_choice

In particular, note that this is already valid code:
[$x => $x * 2]
(A one-element array, specifying the key)

But with the proposal, this would also be perfectly reasonable:
[$x ~> $x * 2]
(A one-element array containing a closure)

So clearly they couldn't share the same syntax.

Regards,

--
Rowan Collins
[IMSoP]

Björn Larsson

10 years ago

Den 2015-08-31 kl. 21:29, skrev Bob Weinand:

> I had this RFC in draft since some time, but delayed it due to all the ongoing PHP 7 discussions. Also we have no master branch to merge features in until 5.4 EOL. Thus I'm reviving this now.
>
> Time for the first RFC targeting PHP 7.1 (assuming PHP 8 isn't going to be the next version ;-)):
>
> The short Closures RFC:
> https://wiki.php.net/rfc/short_closures
>
> Hoping for constructive feedback,
> Bob

Why not supporting default values for arguments like the existing syntax?
Also, if it's easy to implement return types, why not? I know it's
half-baked
but it was a separate RFC for 7.0.

Regards //Björn Larsson
|
|

Andrew Faulds

10 years ago

Hi Bob,

This has probably already come up, but I'd like to weigh in on the
symbol choice.

On the subject of syntax, ~> (let's call it the squiggle arrow) seems
like a very poor choice compared to ==> (let's call it Hack's arrow).

I think it's been mentioned that ==>, Hack's arrow, was thought to be
likely to be confused with =>, the key/value separator in array() and
foreach(). But I'd argue this is actually rather unlikely, for two reasons.

The first of these is that ==> is a whole column wider. So, if there's a
smudge on the screen or something, you could still clearly distinguish
==> from =>. They're visually distinct, much like =, == and === are,
which I'm sure any PHP programmer can tell apart.

Second, => is only used in very limited contexts. You can't use => in a
normal expression or statement. You can't mistake ($t ==> $f ==> $t) for
($t => $f => $t) for long, because the latter would never be a valid
expression. And in the contexts where => does work, it's unlikely you'd
be using a closure  at least, I can't think of a case where you'd want
to create a numeric array of closures using a literal.

For those two reasons, I don't agree that confusing ==> with => would be
a big problem.

Now ~>, the squiggle arrow, was supposedly chosen to reduce the
likelihood of confusion. However, I would argue that it is actually
*more* likely to cause confusion. In this case the potential confusion
would be with ->, the object property dereference operator. I have two
reasons for why the two operators would be confused, and they're the
respective inverses of the reasons why => and ==> wouldn't.

First, ~> visually takes up the same amount of space as ->, so if you
have a small character size, a blurry or low-resolution screen, or poor
eyesight, there's nothing aside from the very slight curvature (and
maybe syntax highlighting, which does not yet exist) to distinguish ~>
from ->.

Second, ->, the object property dereference operator, is used in a wide
range of contexts. It's a valid expression (and thus statement), and so
would crop up in many places where ~>, the squiggle arrow, also would. A
realistic example of this is the Church Booleans, an encoding of the
boolean values "true" and "false" in the lambda calculus: "true" is a
function that takes two arguments and returns the first, and "false" is
a function that takes two arguments and returns the second. The "true"
function would be written, using squiggle arrows, as ($a ~> $b ~> $a).
Now, if you squint, can you tell that apart from ($a ~> $b -> $a)? Did
you even notice the difference in that second expression? (The second
squiggle arrow become a dereference operator.) I wouldn't be surprised
if you didn't. And the difference wouldn't always be immediately obvious
from context. Here, the unusual spacing might give it away (a variable
property access would usually be $b->$a), but not everyone is going to
put spaces around their squiggle arrows.

For those two reasons alone, I think ~> is a poor choice. And that's
without the ugliness issue: in some fonts, particularly Japanese ones, ~
is rendered at the top of the character box, like an overline. In such a
font, ~> will not look like an arrow.

You did mention that the HHVM team might find things easier if you chose
~> instead of ==>, given Hack already has ==>. Surely, though, that only
matters if ==> has different semantics in PHP and Hack, yet this
proposal matches Hack's implementation exactly, so far as I can tell.
Also, it would be nice if PHP and Hack don't diverge when implementing
the same features, unless there's a particularly good reason... it's not
very kind to people who use both languages.

So, to conclude, I would urge you to change the RFC to use ==> instead
of ~>.

Thanks.

--
Andrea Faulds
http://ajf.me/

Pavel Kouřil

10 years ago

On Sun, Sep 6, 2015 at 11:54 PM, Andrea Faulds <ajf@ajf.me> wrote:

> Hi Bob,
>
> This has probably already come up, but I'd like to weigh in on the symbol
> choice.
>
> On the subject of syntax, ~> (let's call it the squiggle arrow) seems like a
> very poor choice compared to ==> (let's call it Hack's arrow).
>
> I think it's been mentioned that ==>, Hack's arrow, was thought to be likely
> to be confused with =>, the key/value separator in array() and foreach().
> But I'd argue this is actually rather unlikely, for two reasons.
>
> The first of these is that ==> is a whole column wider. So, if there's a
> smudge on the screen or something, you could still clearly distinguish ==>
> from =>. They're visually distinct, much like =, == and === are, which I'm
> sure any PHP programmer can tell apart.
>
> Second, => is only used in very limited contexts. You can't use => in a
> normal expression or statement. You can't mistake ($t ==> $f ==> $t) for ($t
> => $f => $t) for long, because the latter would never be a valid expression.
> And in the contexts where => does work, it's unlikely you'd be using a
> closure – at least, I can't think of a case where you'd want to create a
> numeric array of closures using a literal.
>
> For those two reasons, I don't agree that confusing ==> with => would be a
> big problem.
>
> Now ~>, the squiggle arrow, was supposedly chosen to reduce the likelihood
> of confusion. However, I would argue that it is actually *more* likely to
> cause confusion. In this case the potential confusion would be with ->, the
> object property dereference operator. I have two reasons for why the two
> operators would be confused, and they're the respective inverses of the
> reasons why => and ==> wouldn't.
>
> First, ~> visually takes up the same amount of space as ->, so if you have a
> small character size, a blurry or low-resolution screen, or poor eyesight,
> there's nothing aside from the very slight curvature (and maybe syntax
> highlighting, which does not yet exist) to distinguish ~> from ->.
>
> Second, ->, the object property dereference operator, is used in a wide
> range of contexts. It's a valid expression (and thus statement), and so
> would crop up in many places where ~>, the squiggle arrow, also would. A
> realistic example of this is the Church Booleans, an encoding of the boolean
> values "true" and "false" in the lambda calculus: "true" is a function that
> takes two arguments and returns the first, and "false" is a function that
> takes two arguments and returns the second. The "true" function would be
> written, using squiggle arrows, as ($a ~> $b ~> $a). Now, if you squint, can
> you tell that apart from ($a ~> $b -> $a)? Did you even notice the
> difference in that second expression? (The second squiggle arrow become a
> dereference operator.) I wouldn't be surprised if you didn't. And the
> difference wouldn't always be immediately obvious from context. Here, the
> unusual spacing might give it away (a variable property access would usually
> be $b->$a), but not everyone is going to put spaces around their squiggle
> arrows.
>
> For those two reasons alone, I think ~> is a poor choice. And that's without
> the ugliness issue: in some fonts, particularly Japanese ones, ~ is rendered
> at the top of the character box, like an overline. In such a font, ~> will
> not look like an arrow.
>
> You did mention that the HHVM team might find things easier if you chose ~>
> instead of ==>, given Hack already has ==>. Surely, though, that only
> matters if ==> has different semantics in PHP and Hack, yet this proposal
> matches Hack's implementation exactly, so far as I can tell. Also, it would
> be nice if PHP and Hack don't diverge when implementing the same features,
> unless there's a particularly good reason... it's not very kind to people
> who use both languages.
>
> So, to conclude, I would urge you to change the RFC to use ==> instead of
> ~>.
>
> Thanks.
>
> --
> Andrea Faulds
> http://ajf.me/
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Hello,

these are all good points.

Also, I realized it's definitely harder to write ~ than =. On my
keyboard layout (Czech Qwerty) I have to do "right alt + shift + (key
above Tab)". I'm not sure how it is with other non-US keyboard
layouts, but it might be worth exploring before deciding on a symbol;
or maybe there's a possibility that my keyboard layout is just an
anomaly and you can write ~ on most keyboard layouts with a single key
(or double).

Regards
PK

Marco Pivetta

10 years ago

On 7 September 2015 at 06:33, Pavel Kouřil <pajousek@gmail.com> wrote:

> Hello,
>
> these are all good points.
>
> Also, I realized it's definitely harder to write ~ than =. On my
> keyboard layout (Czech Qwerty) I have to do "right alt + shift + (key
> above Tab)". I'm not sure how it is with other non-US keyboard
> layouts, but it might be worth exploring before deciding on a symbol;
> or maybe there's a possibility that my keyboard layout is just an
> anomaly and you can write ~ on most keyboard layouts with a single key
> (or double).
>
> Regards
> PK

The same usually applies to ~, {, }, [ and ].
I personally stopped buying non-en_US keyboards and that's it.
Basically, if you code you kinda want to use en_US layout anyway (or dvorak
if you had too much free time).
I realize that this is unfriendly to beginners, but the ~ already is part
of the syntax of the language anyway.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Andrew Faulds

10 years ago

Hi Marco,

Marco Pivetta wrote:

> On 7 September 2015 at 06:33, Pavel Kouřil <pajousek@gmail.com> wrote:
>>
>> Also, I realized it's definitely harder to write ~ than =. On my
>> keyboard layout (Czech Qwerty) I have to do "right alt + shift + (key
>> above Tab)". I'm not sure how it is with other non-US keyboard
>> layouts, but it might be worth exploring before deciding on a symbol;
>> or maybe there's a possibility that my keyboard layout is just an
>> anomaly and you can write ~ on most keyboard layouts with a single key
>> (or double).
>>
>
> The same usually applies to ~, {, }, [ and ].
> I personally stopped buying non-en_US keyboards and that's it.
> Basically, if you code you kinda want to use en_US layout anyway (or dvorak
> if you had too much free time).
> I realize that this is unfriendly to beginners, but the ~ already is part
> of the syntax of the language anyway.

This sounds a little elitist to me. Learning a new keyboard layout is a
hassle and it's not fair to expect non-Americans to go to extra lengths.
The vast majority of the people in the world aren't American, and even
if a majority of programmers are, that won't remain the case for long.

Of course, we can't accomodate every keyboard layout perfectly, but we
should still take these things into account.

Thanks.

--
Andrea Faulds
http://ajf.me/

Pavel Kouřil

10 years ago

On Mon, Sep 7, 2015 at 8:24 AM, Marco Pivetta <ocramius@gmail.com> wrote:

>
> The same usually applies to ~, {, }, [ and ].
> I personally stopped buying non-en_US keyboards and that's it.
> Basically, if you code you kinda want to use en_US layout anyway (or dvorak
> if you had too much free time).
> I realize that this is unfriendly to beginners, but the ~ already is part of
> the syntax of the language anyway.
>
> Marco Pivetta
>

Hi,

I know this is a problem with more symbols that just ~, and can be
really keyboard layout specific.

That's why I didn't mean it as a "blocker" for the ~ symbol, but more
like a thing to consider for the case the discussion would end up with
deciding between ==> and ~> with no real "preference". I'm sorry if it
did look differently. :)

Personally, I don't have an issue with writing either of those
variants and would be fine with either in the end (I can write ==> a
little bit faster and comfortably - since I can write it with just one
hand - but the difference is not THAT big), but I thought it's worth
mentioning.


PK

Rowan Collins

10 years ago

Andrea Faulds wrote on 06/09/2015 22:54:

> Also, it would be nice if PHP and Hack don't diverge when implementing
> the same features, unless there's a particularly good reason... it's
> not very kind to people who use both languages.

While I agree with the sentiment of them not diverging, the problem is
that it gives the authors of Hack a disproportionate influence on PHP.
At the extreme, if someone wanted to push through their version of a
feature, they could get it released in Hack first, then raise an RFC
citing Hack compatibility as the reason for the design decisions.
(Important: I am not accusing anyone of doing this.)

At the end of the day, the whole point in Hack being its own language,
not just "incompatible features of the HHVM runtime" is surely that it
*can* diverge if it wants to.

Now, that's not a reason for making features different just for the sake
of it; just that "Hack does it that way" should be more of a tie-breaker
than a major decision point, IMHO.

Regards,

--
Rowan Collins
[IMSoP]

Anthony Ferrara

10 years ago

Rowan

On Mon, Sep 7, 2015 at 10:14 PM, Rowan Collins <rowan.collins@gmail.com> wrote:

> Andrea Faulds wrote on 06/09/2015 22:54:
>>
>> Also, it would be nice if PHP and Hack don't diverge when implementing the
>> same features, unless there's a particularly good reason... it's not very
>> kind to people who use both languages.
>
>
> While I agree with the sentiment of them not diverging, the problem is that
> it gives the authors of Hack a disproportionate influence on PHP. At the
> extreme, if someone wanted to push through their version of a feature, they
> could get it released in Hack first, then raise an RFC citing Hack
> compatibility as the reason for the design decisions. (Important: I am not
> accusing anyone of doing this.)t, IMHO.

Being completely fair, doesn't this actually make HackLang a great
test-bed for PHP features? If they implement something, and people
hate it/it sucks, boom. But if people love it, it's a no brainer for
us to "steal".

I don't think we should blindly accept anything because it's in hack,
but the fact that it's there means we also shouldn't diverge "just
because". If it makes sense to copy it, why not?

The one thing I think we absolutely MUST avoid is changing behaviour
slightly but keeping same syntax.

For example, if we used ==> for short closures but used a different
semantic. That would be *really* bad. That leaves us with either
taking their semantics whole sale for the feature, or creating our own
syntax. That's what Bob has proposed here.

Overall, I think we should steal outright what makes sense (I use
steal weakly here, it's collaborative). We should take inspiration
where it makes sense, and we should forge our own road where it makes
sense.

I have not a single ounce of reservation about "giving authors of Hack
a disproportionate influence on PHP". They are not being given a blank
check, no more than any other contributor is. But we also shouldn't be
stupid and ignore what they are doing because of pride (or whatever
else).

My $0.02

Anthony

Rowan Collins

10 years ago

Anthony Ferrara wrote on 07/09/2015 11:23:

> Being completely fair, doesn't this actually make HackLang a great
> test-bed for PHP features? If they implement something, and people
> hate it/it sucks, boom. But if people love it, it's a no brainer for
> us to "steal".
>
> I don't think we should blindly accept anything because it's in hack,
> but the fact that it's there means we also shouldn't diverge "just
> because". If it makes sense to copy it, why not?
>
> The one thing I think we absolutely MUST avoid is changing behaviour
> slightly but keeping same syntax.
>
> For example, if we used ==> for short closures but used a different
> semantic. That would be *really* bad. That leaves us with either
> taking their semantics whole sale for the feature, or creating our own
> syntax. That's what Bob has proposed here.
>
> Overall, I think we should steal outright what makes sense (I use
> steal weakly here, it's collaborative). We should take inspiration
> where it makes sense, and we should forge our own road where it makes
> sense.
>
> I have not a single ounce of reservation about "giving authors of Hack
> a disproportionate influence on PHP". They are not being given a blank
> check, no more than any other contributor is. But we also shouldn't be
> stupid and ignore what they are doing because of pride (or whatever
> else).
>
> My $0.02
>
> Anthony

I agree 100% with this; you've put it much better than I did.

The only additional scenario I can see is where Hack's initial
definition of a feature has some problem, and rather than copying that
problem into PHP, we might fix it and leave Hack to do the same when
their process allows (I don't know what the BC policy on Hack is). That
would be an exception where keeping syntax but varying semantics *might*
make sense, if the communication between teams was clear that the
semantics would be realigned later.

Regards,

--
Rowan Collins
[IMSoP]

Andrew Faulds

10 years ago

Hi Anthony,

Anthony Ferrara wrote:

>
> Being completely fair, doesn't this actually make HackLang a great
> test-bed for PHP features? If they implement something, and people
> hate it/it sucks, boom. But if people love it, it's a no brainer for
> us to "steal".
>
> I don't think we should blindly accept anything because it's in hack,
> but the fact that it's there means we also shouldn't diverge "just
> because". If it makes sense to copy it, why not?
>

Couldn't have put that better myself.

Thanks.

--
Andrea Faulds
http://ajf.me/

Stas Malyshev

10 years ago

Hi!

> Being completely fair, doesn't this actually make HackLang a great
> test-bed for PHP features? If they implement something, and people

I'm not sure how it can be a testbed for *PHP* features, if they develop
them with next to no input from PHP community. At least as far as I
know, maybe I don't know something?

> hate it/it sucks, boom. But if people love it, it's a no brainer for
> us to "steal".

Unless I'm missing something, "people" here are mostly those that work
for Facebook, which, while a sizeable number, is not exactly the whole
PHP community. And I'm not sure even how would we know whether Facebook
developers like it or not - is there some process of evaluating
features? Some kind of community discussion process, voting, feedback
channels that we can observe and learn what people think? What one does
if she works for Facebook and hates how Hack behaves - what is the
feedback system, how it works? I honestly have no idea.

> The one thing I think we absolutely MUST avoid is changing behaviour
> slightly but keeping same syntax.

I agree here that if you already borrow syntax, then using different
semantics makes little sense. That said, I see no reason to borrow
syntax just because Hack does it. If we have a number of languages doing
it the same way - that's fine, it relies on existing mindshare, that's
useful. But otherwise, if we consider borrowing syntax and having to be
constrained by implied semantics and not borrowing syntax and be free to
develop semantics that suits us the most - I'd rather choose not
borrowing. Not because of obsessive desire to be different, but because
of the freedom of the implied constraints. Of course, if after
consideration it turns out the Hack semantics is exactly what we want,
then the same syntax would be a boon.

> a disproportionate influence on PHP". They are not being given a blank
> check, no more than any other contributor is. But we also shouldn't be

The status of "PHP feature testbed" that you are proposing is way more
than any other contributor gets. Which is fine, but not if we run of
danger of dismissing important concerns because "well, Hack did it this
way so it's decided". That is what I'd very much like to avoid.

--
Stas Malyshev
smalyshev@gmail.com

Robert Stoll

10 years ago

Hi Bob

> -----Ursprüngliche Nachricht-----
> Von: Bob Weinand [mailto:bobwei9@hotmail.com]
> Gesendet: Montag, 31. August 2015 21:29
> An: PHP Internals
> Betreff: [PHP-DEV] [RFC] [Discussion] Short Closures
>
> I had this RFC in draft since some time, but delayed it due to all the ongoing PHP 7 discussions. Also we have no

master

> branch to merge features in until 5.4 EOL. Thus I'm reviving this now.
>
> Time for the first RFC targeting PHP 7.1 (assuming PHP 8 isn't going to be the next version ;-)):
>
> The short Closures RFC:
> https://wiki.php.net/rfc/short_closures
>
> Hoping for constructive feedback,
> Bob
> --
> PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

I would like to see a short syntax for closures in PHP but would suggest to use different symbols for the operator. Why
not use --> ?

Nikita

10 years ago

On Mon, 07 Sep 2015 11:46:18 +0300, Robert Stoll <php@tutteli.ch> wrote:

> Hi Bob
>
>> -----Ursprüngliche Nachricht-----
>> Von: Bob Weinand [mailto:bobwei9@hotmail.com]
>> Gesendet: Montag, 31. August 2015 21:29
>> An: PHP Internals
>> Betreff: [PHP-DEV] [RFC] [Discussion] Short Closures
>>
>> I had this RFC in draft since some time, but delayed it due to all the
>> ongoing PHP 7 discussions. Also we have no
> master
>> branch to merge features in until 5.4 EOL. Thus I'm reviving this now.
>>
>> Time for the first RFC targeting PHP 7.1 (assuming PHP 8 isn't going to
>> be the next version ;-)):
>>
>> The short Closures RFC:
>> https://wiki.php.net/rfc/short_closures
>>
>> Hoping for constructive feedback,
>> Bob
>> --
>> PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
>> visit: http://www.php.net/unsub.php
>
> I would like to see a short syntax for closures in PHP but would suggest
> to use different symbols for the operator. Why
> not use --> ?
>

--> is a shift-reduce conflict. It's undecidable if this expression should
return boolean or a closure:
`$foo-->$bar` (is it `$foo --> $bar` or `$foo-- > $bar`)

Robert Stoll

10 years ago

> > I would like to see a short syntax for closures in PHP but would
> > suggest to use different symbols for the operator. Why not use --> ?
> >
>
> --> is a shift-reduce conflict. It's undecidable if this expression
> --> should
> return boolean or a closure:
> `$foo-->$bar` (is it `$foo --> $bar` or `$foo-- > $bar`)
>
> --

You're right, I forgot about the post decrement operator.   What about -=> ? would look like a little rocket ^^ but well, it does not really look better than ~>

Alex Sky

10 years ago

I like many the developers of PHP, write JS lot code, very beg you, if
you can do syntax in ECMAScript 6 (=>)

Thank.