Re: [PHP-DEV] [RFC] [Discussion] Short Closures

Den 2015-09-10 kl. 22:22, skrev Bob Weinand: Am 10.09.2015 um 22:04 schrieb Björn Larsson : 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,

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

> Am 10.09.2015 um 22:04 schrieb Björn Larsson : > > 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 ) ~> expre

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

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

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

On Sep 6, 2015, at 18:19, Bob Weinand wrote: > Oh, I thought that feature to be Hack-only. Looks like I'm wrong and hence > looked at the wrong place. [I always heard Hack has short Closures, but never > was told HHVM had them too...] Semantics semantics semantics. Short closures *are* only su

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

> I think a possible improvement might be a generalised syntax, similar to > that used for constants, that lets you use any \Closure object to define a > function or method. Thus: > > function reduce = $initial ~> $fn ~> $input ~> { > // ... > }; I like this but we're getting a bit

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

Hi Levi, Levi Morrison wrote: If this RFC passes I'd like to see one that builds on it to remove the { return ;} boilerplate of the above definition: function reduce ($initial) ~> $fn ~> $input { $accumulator = $initial; foreach ($input as $value) { $accumul

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

Levi Morrison wrote on 07/09/2015 17:56: function reduce ($initial) ~> $fn ~> $input ~> { $accumulator = $initial; foreach ($input as $value) { $accumulator = $fn($accumulator, $value); } return $accumulator; } Hm, this is an interestin

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

Levi Morrison wrote on 07/09/2015 17:56: >Sort of - the chaining is far from self-explanatory, and some of it is still >rather artificial. For instance, surely map would in reality have been a >named function: > >function map($fn) { > return $input ~> { > foreach ($input a

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

On Mon, Sep 7, 2015 at 6:22 AM, Rowan Collins wrote: > Levi Morrison wrote on 04/09/2015 18:34: >> >> Hopefully I've been able to demonstrate that this style of coding is >> powerful and that the chaining of closures was helpful. > > > Sort of - the chaining is far from self-explanatory, and some

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

Levi Morrison wrote on 04/09/2015 18:34: Hopefully I've been able to demonstrate that this style of coding is powerful and that the chaining of closures was helpful. Sort of - the chaining is far from self-explanatory, and some of it is still rather artificial. For instance, surely map would i

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

> Am 07.09.2015 um 02:59 schrieb Sara Golemon : > > On Sep 6, 2015, at 07:01, Bob Weinand wrote: >> Also, Hack is using a completely different parser, doesn't look like we >> could borrow anything there. >> > True, Hack's parser is ocaml based and unrecognizable to the majority of this > list.

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

On Sep 6, 2015, at 07:01, Bob Weinand wrote: > Also, Hack is using a completely different parser, doesn't look like we could > borrow anything there. > True, Hack's parser is ocaml based and unrecognizable to the majority of this list. But HHVM's parser (which implements the runtime side of Ha

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

> Am 06.09.2015 um 12:54 schrieb Björn Larsson : > > Den 2015-09-05 kl. 14:47, skrev Bob Weinand: >>> Am 05.09.2015 um 11:34 schrieb Björn Larsson >> >: >>> >>> Den 2015-08-31 kl. 21:29, skrev Bob Weinand: I had this RFC in draft since some time, but delayed

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

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

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

(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` th

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

> 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

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

On 4 September 2015 at 09:43, Pavel Kouřil wrote: > On Fri, Sep 4, 2015 at 8:57 AM, Peter Lind wrote: > > On 4 September 2015 at 08:44, Pavel Kouřil wrote: > > > > You're arguing that, subjectively, to you - parentheses make things > harder > > to read. For others they clarify things. > > It sh

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

On Fri, Sep 4, 2015 at 8:57 AM, Peter Lind wrote: > On 4 September 2015 at 08:44, Pavel Kouřil 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 discu

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

On 4 September 2015 at 08:44, Pavel Kouřil 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

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

On Thu, Sep 3, 2015 at 11:56 AM, Rowan Collins 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 >>

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

On Wed, Sep 2, 2015 at 3:48 PM, Rowan Collins 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

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

Tom Worster wrote on 03/09/2015 15:46: The unspoken rules of civility make some people suppress negative reactions to the proposal. In this case it was even implied, as you point out, that dissenting opinion is unwelcome. But I don't think such constraints are entirely fair so I gave my opinion.

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

On 9/2/15 5:34 PM, Rowan Collins wrote:> On 02/09/2015 20:44, Tom Worster wrote: >> In other words, ~> will end my career. Thanks :P > > I know this line is just hyperbole, but it does rather sum up the tone > of the rest of your e-mail. I'm honestly not sure how you expect anyone > to respond. T

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

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

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

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 woud

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

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

Re: [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 ;

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

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

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

On Thu, Sep 3, 2015 at 12:48 AM, Rowan Collins 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-express

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

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

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

On Mon, Aug 31, 2015 at 12:29 PM, Bob Weinand 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 ano

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

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

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

On 01/09/15 07:51, Stanislav Malyshev wrote: >> 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 su

RE: [PHP-DEV] [RFC] [Discussion] Short Closures

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

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

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 PH

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

On Tue, Sep 1, 2015 at 10:45 AM, Tony Marston wrote: > > 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) Introdu

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

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

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

On Tue, Sep 1, 2015 at 10:44 AM, Anthony Ferrara 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 var

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

"Yasuo Ohgaki" wrote in message news:caga2bxzpud0j86d-vlsc+fukhzrjk_3qu_5afkg0bm+de7x...@mail.gmail.com... Hi Anthony and Bob, On Tue, Sep 1, 2015 at 2:53 PM, Anthony Ferrara wrote: Most programming languages today have a "short form" closure or lambda syntax HackLang: ($x) ==> $x + 1; C+

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

Pavel On Tue, Sep 1, 2015 at 4:32 AM, Pavel Kouřil wrote: > On Mon, Aug 31, 2015 at 9:29 PM, 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

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

On Mon, Aug 31, 2015 at 9:29 PM, 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 (

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

On Tue, Sep 1, 2015 at 9:36 AM, Yasuo Ohgaki wrote: > Hi Anthony and Bob, > > On Tue, Sep 1, 2015 at 2:53 PM, Anthony Ferrara > wrote: > > Most programming languages today have a "short form" closure or lambda > syntax > > > > HackLang: ($x) ==> $x + 1; > > C++: [](int x) -> int { return x + 1;

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

Hi Anthony and Bob, On Tue, Sep 1, 2015 at 2:53 PM, Anthony Ferrara 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|

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

2015. aug. 31. 21:29 ezt írta ("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

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

Hey: On Tue, Sep 1, 2015 at 2:51 PM, Stanislav Malyshev wrote: > 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

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

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 sayin

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

Stas, On Mon, Aug 31, 2015 at 11:46 PM, Stanislav Malyshev 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

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

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

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

> Am 01.09.2015 um 04:55 schrieb Rasmus Lerdorf : > >> On Aug 31, 2015, at 18:04, Bob Weinand 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 implementat

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

> On Aug 31, 2015, at 18:04, Bob Weinand 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,

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

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

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

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

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

On Tue, 01 Sep 2015 00:05:35 +0300, Stanislav Malyshev 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

Re: [PHP-DEV] [RFC] [Discussion] Short Closures

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 versi