# [RFC] [Discussion] Short Closures

- Thread: https://externals.io/message/87958
- Original archive: https://news-web.php.net/php.internals/87958
- Started by Bob Weinand on 2015-08-31T19:29:18+00:00
- Messages: 65
- RFC: Short Closures (~> operator) (Withdrawn) — https://externals.io/rfc/short_closures.md
- Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/87958.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #87958 — Bob Weinand — 2015-08-31T19:29:18+00:00

URL: https://externals.io/message/87958#87958

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

---

## #87961 — Stanislav Malyshev — 2015-08-31T21:05:35+00:00

URL: https://externals.io/message/87958#87961 · In reply to: #87958

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

---

## #87963 — Nikita Nefedov — 2015-08-31T21:32:07+00:00

URL: https://externals.io/message/87958#87963 · In reply to: #87961

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

> Hi!
>
> > […]
>
> 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...

---

## #87966 — Stanislav Malyshev — 2015-09-01T00:24:09+00:00

URL: https://externals.io/message/87958#87966 · In reply to: #87963

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

---

## #87967 — Bob Weinand — 2015-09-01T01:04:55+00:00

URL: https://externals.io/message/87958#87967 · In reply to: #87966

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!
> 
> > […]
> 
> Shrtr dsnt lwys mks thngs esr 2 rd.
> Sometimes it's quite the opposite.
> 
> > […]
> 
> 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).

> > […]
> 
> 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.

> > […]
> 
> 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.
> 
> > […]
> 
> 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.

> > […]
> 
> 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

---

## #87969 — Rasmus Lerdorf — 2015-09-01T02:55:00+00:00

URL: https://externals.io/message/87958#87969 · In reply to: #87967

> 
> 
> From the RFC:
> > […]
> 
> 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

---

## #87971 — Bob Weinand — 2015-09-01T03:08:57+00:00

URL: https://externals.io/message/87958#87971 · In reply to: #87969

> Am 01.09.2015 um 04:55 schrieb Rasmus Lerdorf <rasmus@lerdorf.com>:
> 
> > […]
> 
> 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?

---

## #87972 — Stanislav Malyshev — 2015-09-01T03:46:50+00:00

URL: https://externals.io/message/87958#87972 · In reply to: #87971

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

---

## #87973 — Anthony Ferrara — 2015-09-01T05:53:41+00:00

URL: https://externals.io/message/87958#87973 · In reply to: #87972

Stas,

On Mon, Aug 31, 2015 at 11:46 PM, Stanislav Malyshev
<smalyshev@gmail.com> wrote:
> Hi!
>
> > […]
>
> 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

---

## #87974 — Stanislav Malyshev — 2015-09-01T06:51:53+00:00

URL: https://externals.io/message/87958#87974 · In reply to: #87973

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

---

## #87975 — Xinchen Hui — 2015-09-01T07:03:50+00:00

URL: https://externals.io/message/87958#87975 · In reply to: #87974

Hey:


> Hi!
>
> > […]
>
> 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.
>
> > […]
>
> 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.
>
> > […]
>
> 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.
>
> > […]
>
> 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.
>
> > […]
>
> 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.
>
> > […]
>
> That's because you wrote it and know in advance what it is supposed to
> do. It's not a good test of readability.

+1, that is what readable(guessable) means.....

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



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

---

## #87976 — Ferenc Kovacs — 2015-09-01T07:18:52+00:00

URL: https://externals.io/message/87958#87976 · In reply to: #87958

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
> --
> 
> 
>

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

---

## #87977 — Yasuo Ohgaki — 2015-09-01T07:36:02+00:00

URL: https://externals.io/message/87958#87977 · In reply to: #87973

Hi Anthony and Bob,


> 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

---

## #87978 — Ferenc Kovacs — 2015-09-01T07:41:39+00:00

URL: https://externals.io/message/87958#87978 · In reply to: #87977

> Hi Anthony and Bob,
>
> On Tue, Sep 1, 2015 at 2:53 PM, Anthony Ferrara <ircmaxell@gmail.com>
> wrote:
> > […]
> syntax
> > […]
>
> 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 "==>"?
>

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

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

---

## #87979 — pajousek@gmail.com — 2015-09-01T08:32:39+00:00

URL: https://externals.io/message/87958#87979 · In reply to: #87958

> 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
> --
> 
> 
>

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

---

## #87980 — Anthony Ferrara — 2015-09-01T08:44:04+00:00

URL: https://externals.io/message/87958#87980 · In reply to: #87979

Pavel


> 
> > […]
>
> 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

---

## #87981 — Tony Marston — 2015-09-01T08:45:38+00:00

URL: https://externals.io/message/87958#87981 · In reply to: #87977

"Yasuo Ohgaki"  wrote in message 
news:CAGa2bXZpUd0J86D-VLSC+fUKhzRJk_3Qu_5afkG0bM+DE7XYew@mail.gmail.com...
>
>Hi Anthony and Bob,
>
>On Tue, Sep 1, 2015 at 2:53 PM, Anthony Ferrara <ircmaxell@gmail.com> 
>wrote:
> > […]
>
>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.

This argument is irrelevant for several reasons:
(1) I am not familiar with any of those languages, nor are many PHP users.
(2) Just because other languages have such a feature is not a good reason 
for adding it into PHP.
(3) Introducing write-only (less readable or completely unreadable) code 
will ALWAYS be a barrier to those who have used nothing but PHP for the last 
10+ years.

As H. Abelson and G. Sussman wrote in 1984: "Programs must be written for 
people to read, and only incidentally for machines to execute." Writing 
compact code which has several functions compressed into a single line may 
be clever where you come from, but it leaves new readers scratching their 
heads saying "WTF!!".

As a follower of the KISS principle I always aim to write simple, readable 
code, and my critics always say "It is too simple. Proper OO is supposed to 
be more complex than that".  The mark of genius is to achieve complex things 
in a simple manner, not to achieve simple things in a complex manner.

-- 
Tony Marston

---

## #87984 — pajousek@gmail.com — 2015-09-01T09:00:08+00:00

URL: https://externals.io/message/87958#87984 · In reply to: #87980

> > […]
>
> 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. :)

> > […]
>
> 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

---

## #87985 — Kingsquare.nl - Robin Speekenbrink — 2015-09-01T09:08:12+00:00

URL: https://externals.io/message/87958#87985 · In reply to: #87980

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>:
> Pavel
>
> 
> > […]
>
> 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.
>
> > […]
>
> 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

---

## #87986 — pajousek@gmail.com — 2015-09-01T09:19:28+00:00

URL: https://externals.io/message/87958#87986 · In reply to: #87981

>
> This argument is irrelevant for several reasons:
> (1) I am not familiar with any of those languages, nor are many PHP users.
> (2) Just because other languages have such a feature is not a good reason
> for adding it into PHP.
> (3) Introducing write-only (less readable or completely unreadable) code
> will ALWAYS be a barrier to those who have used nothing but PHP for the last
> 10+ years.
>
> As H. Abelson and G. Sussman wrote in 1984: "Programs must be written for
> people to read, and only incidentally for machines to execute." Writing
> compact code which has several functions compressed into a single line may
> be clever where you come from, but it leaves new readers scratching their
> heads saying "WTF!!".
>
> As a follower of the KISS principle I always aim to write simple, readable
> code, and my critics always say "It is too simple. Proper OO is supposed to
> be more complex than that".  The mark of genius is to achieve complex things
> in a simple manner, not to achieve simple things in a complex manner.
>

The thing is, every feature and syntax can be used to create some
unreadable "monstrosity". And often, at the same time, they can be
used to create readable elegant code. :)

Sure, "elegant" and "readable" is subjective, and for someone who
never heard of FP, this might be befuddling. But so is probably the
entire concept of anonymous functions and high order functions. Does
it mean PHP shouldn't support passing functions to functions at all? I
think not.

Also, once you know ~> is a syntax sugar for anonymous functions (and
understand them), I don't think there's any general readability
problem, and in some cases, it makes the code even more readable
(subjective experience from other languages). And if the programmer
doesn't understand the concept of anonymous functions at all, he will
be lost anyways and shorter or longer syntax doesn't matter.

I personally wouldn't even mind just having a version that supports
[variables] ~> [single expression], but since other languages support
having whole function body with return statement, I think it's worth
considering adding it too.

Regards
Pavel Kouril

---

## #87990 — Derick Rethans — 2015-09-01T09:48:12+00:00

URL: https://externals.io/message/87958#87990 · In reply to: #87958

> 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

---

## #87991 — Thomas Punt — 2015-09-01T10:37:24+00:00

URL: https://externals.io/message/87958#87991 · In reply to: #87958

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

---

## #87993 — Lester Caine — 2015-09-01T10:50:04+00:00

URL: https://externals.io/message/87958#87993 · In reply to: #87974

> > […]
> 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.

Only entry level programmers?

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

---

## #87994 — Rowan Collins — 2015-09-01T14:21:25+00:00

URL: https://externals.io/message/87958#87994 · In reply to: #87973

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]

---

## #88015 — Sara Golemon — 2015-09-02T21:49:20+00:00

URL: https://externals.io/message/87958#88015 · In reply to: #87958

> 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

---

Next page: https://externals.io/message/87958.md?page=2