Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures

This is only part of a thread. view whole thread
  105165
April 9, 2019 10:19 nikita.ppv@gmail.com (Nikita Popov)
On Tue, Apr 9, 2019 at 8:56 AM Björn Larsson larsson@telia.com>
wrote:

> Den 2019-04-08 kl. 16:06, skrev Nikita Popov: > > > On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov ppv@gmail.com> > wrote: > > > >> Hi internals, > >> > >> Motivated by the recent list comprehensions RFC, I think it's time we > took > >> another look at short closures: > >> > >> https://wiki.php.net/rfc/arrow_functions_v2 > >> > >> This is based on a previous (withdrawn) proposal by Levi & Bob. It uses > >> the syntax > >> > >> fn($x) => $x * $multiplier > >> > >> and implicit by-value variable binding. This example is roughly > equivalent > >> to: > >> > >> function($x) use($multiplier) { return $x * $multiplier; } > >> > >> The RFC contains a detailed discussion of syntax choices and binding > modes. > >> > >> Regards, > >> Nikita > >> > > Heads up: I plan to start voting on this RFC tomorrow if nothing new > comes > > up. > > > > Most of the discussion was (as expected) about the choice of syntax. > > Ultimately I think there are many reasonable choices we can make here, > but > > we should stick to a specific proposal for the purposes of the RFC vote.. > > None of the given arguments convinced me that some other syntax is > > *strictly* better than the proposed fn($x, $y) => $x*$y -- it's more a > > matter of some choices being slightly better in one case and slightly > worse > > in another. My personal runner-up would be \($x, $y) => $x*$y, but I > > suspect that there are some people who are more strongly biased against > > "sigil salad" than I am... > > > > Nikita > Hi, > > I recall that the perception of the ==> syntax in the Hacklang user > community was quite positive. Of course it was implementation > difficulties. Are they still to cumbersome in PHP? > > Personally I prefer that one being more readable or the \ one. > Anyway, glad to see that short closures finally is on the road > again! >
The ==> syntax is the other one I implemented ( https://github.com/php/php-src/pull/3945). The implementation is based on lexer lookahead, which is ugly but still manageable. I haven't seen much support for this variant in this discussion though. And of course, if there's no strong preference for ==>, I'd rather go with the variant that is easier for us (and all 3rd party tooling) to support from a technical perspective. Nikita
  105179
April 9, 2019 15:23 bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)
Den 2019-04-09 kl. 12:19, skrev Nikita Popov:
> On Tue, Apr 9, 2019 at 8:56 AM Björn Larsson larsson@telia.com> > wrote: > >> Den 2019-04-08 kl. 16:06, skrev Nikita Popov: >> >>> On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov ppv@gmail.com> >> wrote: >>>> Hi internals, >>>> >>>> Motivated by the recent list comprehensions RFC, I think it's time we >> took >>>> another look at short closures: >>>> >>>> https://wiki.php.net/rfc/arrow_functions_v2 >>>> >>>> This is based on a previous (withdrawn) proposal by Levi & Bob. It uses >>>> the syntax >>>> >>>> fn($x) => $x * $multiplier >>>> >>>> and implicit by-value variable binding. This example is roughly >> equivalent >>>> to: >>>> >>>> function($x) use($multiplier) { return $x * $multiplier; } >>>> >>>> The RFC contains a detailed discussion of syntax choices and binding >> modes. >>>> Regards, >>>> Nikita >>>> >>> Heads up: I plan to start voting on this RFC tomorrow if nothing new >> comes >>> up. >>> >>> Most of the discussion was (as expected) about the choice of syntax. >>> Ultimately I think there are many reasonable choices we can make here, >> but >>> we should stick to a specific proposal for the purposes of the RFC vote. >>> None of the given arguments convinced me that some other syntax is >>> *strictly* better than the proposed fn($x, $y) => $x*$y -- it's more a >>> matter of some choices being slightly better in one case and slightly >> worse >>> in another. My personal runner-up would be \($x, $y) => $x*$y, but I >>> suspect that there are some people who are more strongly biased against >>> "sigil salad" than I am... >>> >>> Nikita >> Hi, >> >> I recall that the perception of the ==> syntax in the Hacklang user >> community was quite positive. Of course it was implementation >> difficulties. Are they still to cumbersome in PHP? >> >> Personally I prefer that one being more readable or the \ one. >> Anyway, glad to see that short closures finally is on the road >> again! >> > The ==> syntax is the other one I implemented ( > https://github.com/php/php-src/pull/3945). The implementation is based on > lexer lookahead, which is ugly but still manageable. I haven't seen much > support for this variant in this discussion though. And of course, if > there's no strong preference for ==>, I'd rather go with the variant that > is easier for us (and all 3rd party tooling) to support from a technical > perspective. > > Nikita Maybe part of the reason it didn't attract to much support is that people
are quite aware and respect the implementation difficulties. I recall a comment in this thread pointing in that direction. Well it's probably me being a long-time PHP user and now trying to learn RUST that finds the fn() syntax a bit confusing ;-) From that perspective I would prefer the \$x => $x **2 vs fn($x) => $x **2 or the ==> one. r//Björn L
  105185
April 9, 2019 21:52 bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)
Den 2019-04-09 kl. 17:23, skrev Björn Larsson:
> Den 2019-04-09 kl. 12:19, skrev Nikita Popov: >> On Tue, Apr 9, 2019 at 8:56 AM Björn Larsson larsson@telia.com> >> wrote: >> >>> Den 2019-04-08 kl. 16:06, skrev Nikita Popov: >>> >>>> On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov ppv@gmail.com> >>> wrote: >>>>> Hi internals, >>>>> >>>>> Motivated by the recent list comprehensions RFC, I think it's time we >>> took >>>>> another look at short closures: >>>>> >>>>> https://wiki.php.net/rfc/arrow_functions_v2 >>>>> >>>>> This is based on a previous (withdrawn) proposal by Levi & Bob. It >>>>> uses >>>>> the syntax >>>>> >>>>>       fn($x) => $x * $multiplier >>>>> >>>>> and implicit by-value variable binding. This example is roughly >>> equivalent >>>>> to: >>>>> >>>>>       function($x) use($multiplier) { return $x * $multiplier; } >>>>> >>>>> The RFC contains a detailed discussion of syntax choices and binding >>> modes. >>>>> Regards, >>>>> Nikita >>>>> >>>> Heads up: I plan to start voting on this RFC tomorrow if nothing new >>> comes >>>> up. >>>> >>>> Most of the discussion was (as expected) about the choice of syntax. >>>> Ultimately I think there are many reasonable choices we can make here, >>> but >>>> we should stick to a specific proposal for the purposes of the RFC >>>> vote. >>>> None of the given arguments convinced me that some other syntax is >>>> *strictly* better than the proposed fn($x, $y) => $x*$y -- it's more a >>>> matter of some choices being slightly better in one case and slightly >>> worse >>>> in another. My personal runner-up would be \($x, $y) => $x*$y, but I >>>> suspect that there are some people who are more strongly biased >>>> against >>>> "sigil salad" than I am... >>>> >>>> Nikita >>> Hi, >>> >>> I recall that the perception of the ==> syntax in the Hacklang user >>> community was quite positive. Of course it was implementation >>> difficulties. Are they still to cumbersome in PHP? >>> >>> Personally I prefer that one being more readable or the \ one. >>> Anyway, glad to see that short closures finally is on the road >>> again! >>> >> The ==> syntax is the other one I implemented ( >> https://github.com/php/php-src/pull/3945). The implementation is >> based on >> lexer lookahead, which is ugly but still manageable. I haven't seen much >> support for this variant in this discussion though. And of course, if >> there's no strong preference for ==>, I'd rather go with the variant >> that >> is easier for us (and all 3rd party tooling) to support from a technical >> perspective. >> >> Nikita > Maybe part of the reason it didn't attract to much support is that people > are quite aware and respect the implementation difficulties. I recall a > comment in this thread pointing in that direction. > > Well it's probably me being a long-time PHP user and now trying to learn > RUST that finds the fn() syntax a bit confusing ;-) From that > perspective I > would prefer the \$x => $x **2 vs fn($x) => $x **2 or the ==> one. > > r//Björn L > > Hi again,
Just read the RFC a bit closer and saw that \$x is'nt possible, pity. Taking an example from chregu gist with arrow function inside a function call: - $waithandles = $this->urls->map(fn($url) => $this->fetcher->fetch($url)); - $waithandles = $this->urls->map(\($url) => $this->fetcher->fetch($url)); - $waithandles = $this->urls->map($url ==> $this->fetcher->fetch($url)); I would say that when lambda functions occurs in function calls I find the \ or ==> syntax more readable. Over & out //Björn L
  105186
April 9, 2019 22:10 robehickman@gmail.com (Robert Hickman)
> - $waithandles = $this->urls->map(fn($url) => $this->fetcher->fetch($url)); > - $waithandles = $this->urls->map(\($url) => $this->fetcher->fetch($url)); > - $waithandles = $this->urls->map($url ==> $this->fetcher->fetch($url)); > > I would say that when lambda functions occurs in function calls I find the > \ or ==> syntax more readable. >
To me, in that context, '==>' is the most readable as it does not have parentheses on the argument. It's a bit visually noisy with them.
  105190
April 10, 2019 08:01 markus@fischer.name (Markus Fischer)
On 10.04.19 00:10, Robert Hickman wrote:
>> - $waithandles = $this->urls->map(fn($url) => $this->fetcher->fetch($url)); >> - $waithandles = $this->urls->map(\($url) => $this->fetcher->fetch($url)); >> - $waithandles = $this->urls->map($url ==> $this->fetcher->fetch($url)); >> >> I would say that when lambda functions occurs in function calls I find the >> \ or ==> syntax more readable. >> > > To me, in that context, '==>' is the most readable as it does not have > parentheses on the argument. It's a bit visually noisy with them.
I concur, `==>` to me also stands out the most easiest to read without too much parenthesis noise. - Markus
  105192
April 10, 2019 08:33 gadelat@gmail.com (Gabriel O)
Those parentheses are important when having multiple argument

On 10 April 2019 10:02:46 AM Markus Fischer <markus@fischer.name> wrote:

> On 10.04.19 00:10, Robert Hickman wrote: >>> - $waithandles = $this->urls->map(fn($url) => $this->fetcher->fetch($url)); >>> - $waithandles = $this->urls->map(\($url) => $this->fetcher->fetch($url)); >>> - $waithandles = $this->urls->map($url ==> $this->fetcher->fetch($url)); >>> >>> I would say that when lambda functions occurs in function calls I find the >>> \ or ==> syntax more readable. >>> >> >> To me, in that context, '==>' is the most readable as it does not have >> parentheses on the argument. It's a bit visually noisy with them. > > I concur, `==>` to me also stands out the most easiest to read without > too much parenthesis noise. > > - Markus > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php
  105195
April 10, 2019 09:07 markus@fischer.name (Markus Fischer)
Hi, Gabriel,

On 10.04.19 10:33, Gabriel O wrote:
> Those parentheses are important when having multiple argument
Please don't top post, thanks! Thanks for pointing it out, I'm aware. Still `===>` would better stand out to _me_ personally. thanks, - Markus
  105197
April 10, 2019 09:27 benjamin.morel@gmail.com (Benjamin Morel)
I think that the RFC covers a great deal of possible syntaxes and their
tradeoffs.

`==>` requires *a lot* of changes to the current parser, and external
tooling as mentioned by Rowan.

It has not even been specified whether the `==>` syntax could land into PHP
7.4, or could require postponing to PHP 8.0.
I do not think that saving these two little chars `fn` justifies the extra
complexity and possible late adoption, if not by PHP, at least by external
tooling.
Also, extra parser complexity potentially means slower compilation times,
even if it's just during opcache warmup.

@nikic, the RFC does not mention changes to reflection:

- Will arrow functions be accessed through ReflectionFunction as well?
- Will they be distinguishable from regular closures, with a method such as
`isShortClosure()` or `isArrowFunction()`?

Thanks,
Ben



On Wed, 10 Apr 2019 at 11:08, Markus Fischer <markus@fischer.name> wrote:

> Hi, Gabriel, > > On 10.04.19 10:33, Gabriel O wrote: > > Those parentheses are important when having multiple argument > > Please don't top post, thanks! > > Thanks for pointing it out, I'm aware. > > Still `===>` would better stand out to _me_ personally. > > thanks, > - Markus > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
  105193
April 10, 2019 08:39 rowan.collins@gmail.com (Rowan Collins)
On Tue, 9 Apr 2019 at 11:20, Nikita Popov ppv@gmail.com> wrote:

> The ==> syntax is the other one I implemented ( > https://github.com/php/php-src/pull/3945). The implementation is based on > lexer lookahead, which is ugly but still manageable. I haven't seen much > support for this variant in this discussion though. And of course, if > there's no strong preference for ==>, I'd rather go with the variant that > is easier for us (and all 3rd party tooling) to support from a technical > perspective. >
I'd just like to amplify this mention of 3rd party tooling: if we go with something which requires complex lexer/parser rules, then every editor, IDE, and static analysis tool will need to also work with that syntax. For those saying they "slightly prefer" ==> please ask yourself, do you prefer it enough to add complexity to every tool that wants to process PHP source code? Regards, -- Rowan Collins [IMSoP]
  105194
April 10, 2019 08:59 robehickman@gmail.com (Robert Hickman)
> I'd just like to amplify this mention of 3rd party tooling: if we go with > something which requires complex lexer/parser rules, then every editor, > IDE, and static analysis tool will need to also work with that syntax. >
Is this actually a problem? Don't these tools make use of existing parsers like 'php parser', thus the cost is lower than initially apparent?
  105196
April 10, 2019 09:12 rowan.collins@gmail.com (Rowan Collins)
On Wed, 10 Apr 2019 at 09:59, Robert Hickman <robehickman@gmail.com> wrote:

> > I'd just like to amplify this mention of 3rd party tooling: if we go with > > something which requires complex lexer/parser rules, then every editor, > > IDE, and static analysis tool will need to also work with that syntax. > > > > Is this actually a problem? Don't these tools make use of existing > parsers like 'php parser', thus the cost is lower than initially > apparent? >
I don't think you can generalise about "these tools" at all - for instance, PHPStorm is written in Java, and VSCode is written in JS; I doubt they share any parser components with each other, or with anything written in C or PHP itself. We're not just talking about existing tools, either, but every tool created until the language dies. Regards, -- Rowan Collins [IMSoP]
  105198
April 10, 2019 09:35 php-lists@koalephant.com (Stephen Reay)
> On 10 Apr 2019, at 15:59, Robert Hickman <robehickman@gmail.com> wrote: > >> I'd just like to amplify this mention of 3rd party tooling: if we go with >> something which requires complex lexer/parser rules, then every editor, >> IDE, and static analysis tool will need to also work with that syntax. >> > > Is this actually a problem? Don't these tools make use of existing > parsers like 'php parser', thus the cost is lower than initially > apparent? > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
This seems like a risky thing to assume “it’ll be fine” about. I’d like to add my (non-voting) voice in favour of the `fn(…)` syntax. I don’t know that I’d get a lot of use out of short closures anyway, but I’d at least like it to remain readable on the occasion I might use them, or (more likely) work on something where someone else uses them. I question (loudly) any view that less characters is automatically improves readability. I’ve yet to see a project anywhere that suffered overrun or saw low productivity because developers were busy typing/reading parenthesis around argument lists or keywords.
  105215
April 10, 2019 17:18 mo.mu.wss@gmail.com ("M. W. Moe")
Hello,

this is not much the syntax which is problematic here but the implicit
lambda capture ruleset proposed; for that,
it would require (fully justified in this case) a preprocessing step hence
a language contextual analysis step
or what people call `static`.

On Wed, Apr 10, 2019 at 2:35 AM Stephen Reay <php-lists@koalephant.com>
wrote:

> > > On 10 Apr 2019, at 15:59, Robert Hickman <robehickman@gmail.com> wrote: > > > >> I'd just like to amplify this mention of 3rd party tooling: if we go > with > >> something which requires complex lexer/parser rules, then every editor, > >> IDE, and static analysis tool will need to also work with that syntax. > >> > > > > Is this actually a problem? Don't these tools make use of existing > > parsers like 'php parser', thus the cost is lower than initially > > apparent? > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > This seems like a risky thing to assume “it’ll be fine” about. > > I’d like to add my (non-voting) voice in favour of the `fn(…)` syntax. I > don’t know that I’d get a lot of use out of short closures anyway, but I’d > at least like it to remain readable on the occasion I might use them, or > (more likely) work on something where someone else uses them. > > I question (loudly) any view that less characters is automatically > improves readability. I’ve yet to see a project anywhere that suffered > overrun or saw low productivity because developers were busy typing/reading > parenthesis around argument lists or keywords. > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
  105216
April 10, 2019 17:32 mo.mu.wss@gmail.com ("M. W. Moe")
@Stephen Reay,

I have never seen ML programmers being improductive; that's because maybe
you witness  people
unfit for it; math is less character and contextual i.e meanings change
according to environment;
it's fully readable to people fitted for it.

On Wed, Apr 10, 2019 at 10:18 AM M. W. Moe wss@gmail.com> wrote:

> Hello, > > this is not much the syntax which is problematic here but the implicit > lambda capture ruleset proposed; for that, > it would require (fully justified in this case) a preprocessing step hence > a language contextual analysis step > or what people call `static`. > > On Wed, Apr 10, 2019 at 2:35 AM Stephen Reay <php-lists@koalephant.com> > wrote: > >> >> > On 10 Apr 2019, at 15:59, Robert Hickman <robehickman@gmail.com> wrote: >> > >> >> I'd just like to amplify this mention of 3rd party tooling: if we go >> with >> >> something which requires complex lexer/parser rules, then every editor, >> >> IDE, and static analysis tool will need to also work with that syntax.. >> >> >> > >> > Is this actually a problem? Don't these tools make use of existing >> > parsers like 'php parser', thus the cost is lower than initially >> > apparent? >> > >> > -- >> > PHP Internals - PHP Runtime Development Mailing List >> > To unsubscribe, visit: http://www.php.net/unsub.php >> > >> >> This seems like a risky thing to assume “it’ll be fine” about. >> >> I’d like to add my (non-voting) voice in favour of the `fn(…)` syntax. I >> don’t know that I’d get a lot of use out of short closures anyway, but I’d >> at least like it to remain readable on the occasion I might use them, or >> (more likely) work on something where someone else uses them. >> >> I question (loudly) any view that less characters is automatically >> improves readability. I’ve yet to see a project anywhere that suffered >> overrun or saw low productivity because developers were busy typing/reading >> parenthesis around argument lists or keywords. >> >> >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >>
  105230
April 11, 2019 04:23 php-lists@koalephant.com (Stephen Reay)
> On 11 Apr 2019, at 00:32, M. W. Moe wss@gmail.com> wrote: > > I have never seen ML programmers being improductive;
Great. I’ve never seen a pig crash a plane, therefore all pilots should be pigs? Given your previous comments regarding removing “java impurities” it’s hard to take anything you suggest seriously.
  105240
April 11, 2019 14:51 mo.mu.wss@gmail.com ("M. W. Moe")
@Stephen Reay

i) Good for you!, if you say so must be the truth; yes php still suffers of
it's java-like-transform; historically named php5;
repeating the same design traps almost 20 years after it; and in the
real-life the most interesting inquiries about the language evolution are
blocked by this fact and make tedious what would look like very simple
changes.

ii) BTW, that's you making personal experience an absolute rule and
projecting your own limitations as a valuable intellectual argument; , not
myself; my remark was just an illustration.

You have a good day!







On Wed, Apr 10, 2019 at 9:23 PM Stephen Reay <php-lists@koalephant.com>
wrote:

> > > On 11 Apr 2019, at 00:32, M. W. Moe wss@gmail.com> wrote: > > > > I have never seen ML programmers being improductive; > > Great. I’ve never seen a pig crash a plane, therefore all pilots should be > pigs? > > Given your previous comments regarding removing “java impurities” it’s > hard to take anything you suggest seriously. > > >
  105241
April 11, 2019 14:58 benjamin.morel@gmail.com (Benjamin Morel)
> yes php still suffers of > it's java-like-transform; historically named php5; > repeating the same design traps almost 20 years after it;
Maybe you could just switch to another language then, and bother another mailing list? On Thu, 11 Apr 2019 at 16:51, M. W. Moe wss@gmail.com> wrote:
> @Stephen Reay > > i) Good for you!, if you say so must be the truth; yes php still suffers of > it's java-like-transform; historically named php5; > repeating the same design traps almost 20 years after it; and in the > real-life the most interesting inquiries about the language evolution are > blocked by this fact and make tedious what would look like very simple > changes. > > ii) BTW, that's you making personal experience an absolute rule and > projecting your own limitations as a valuable intellectual argument; , not > myself; my remark was just an illustration. > > You have a good day! > > > > > > > > On Wed, Apr 10, 2019 at 9:23 PM Stephen Reay <php-lists@koalephant.com> > wrote: > > > > > > On 11 Apr 2019, at 00:32, M. W. Moe wss@gmail.com> wrote: > > > > > > I have never seen ML programmers being improductive; > > > > Great. I’ve never seen a pig crash a plane, therefore all pilots should > be > > pigs? > > > > Given your previous comments regarding removing “java impurities” it’s > > hard to take anything you suggest seriously. > > > > > > >
  105242
April 11, 2019 15:15 mo.mu.wss@gmail.com ("M. W. Moe")
@Benjamin Morel

why? if voicing reasonable criticisms is bothering you; then you should do
something else in life;
because engineering is built on this `very` concept; I am not in the apex
or any emotional trend;
it does not interest me.

 You have a good day!

On Thu, Apr 11, 2019 at 7:58 AM Benjamin Morel morel@gmail.com>
wrote:

> > yes php still suffers of > > it's java-like-transform; historically named php5; > > repeating the same design traps almost 20 years after it; > > Maybe you could just switch to another language then, and bother another > mailing list? > > > On Thu, 11 Apr 2019 at 16:51, M. W. Moe wss@gmail.com> wrote: > >> @Stephen Reay >> >> i) Good for you!, if you say so must be the truth; yes php still suffers >> of >> it's java-like-transform; historically named php5; >> repeating the same design traps almost 20 years after it; and in the >> real-life the most interesting inquiries about the language evolution are >> blocked by this fact and make tedious what would look like very simple >> changes. >> >> ii) BTW, that's you making personal experience an absolute rule and >> projecting your own limitations as a valuable intellectual argument; , not >> myself; my remark was just an illustration. >> >> You have a good day! >> >> >> >> >> >> >> >> On Wed, Apr 10, 2019 at 9:23 PM Stephen Reay <php-lists@koalephant.com> >> wrote: >> >> > >> > > On 11 Apr 2019, at 00:32, M. W. Moe wss@gmail.com> wrote: >> > > >> > > I have never seen ML programmers being improductive; >> > >> > Great. I’ve never seen a pig crash a plane, therefore all pilots should >> be >> > pigs? >> > >> > Given your previous comments regarding removing “java impurities” it’s >> > hard to take anything you suggest seriously. >> > >> > >> > >> >
  105246
April 11, 2019 16:15 benjamin.morel@gmail.com (Benjamin Morel)
> why? if voicing reasonable criticisms is bothering you; then you should do something else in life;
> because engineering is built on this `very` concept;
You're very welcome to challenge the "java impurities" that have been a foundation of the language for 15 years—although you may better invest your own time by switching to another language that's already closer to what you expect. But calling people pigs when they disagree with you is not what I'd call reasonable criticism.
> I am not in the apex or any emotional trend; it does not interest me.
Oh that's exactly the impression you've left so far.
  105247
April 11, 2019 16:38 robehickman@gmail.com (Robert Hickman)
@M. W. Moe If you don't like the java-isms you can ignore them to a
large extent, which I do. However in doing so you're going against the
grain and will end up writing a lot of stuff yourself. I do find it
weird how PHP has morphed so drastically from it's origins and also
wander why. If people wanted a Java-esque language, why not use Java
in the first place?

This discussion is off topic.

On Thu, 11 Apr 2019 at 17:15, Benjamin Morel morel@gmail.com> wrote:
> > > why? if voicing reasonable criticisms is bothering you; then you should > do something else in life; > > because engineering is built on this `very` concept; > > You're very welcome to challenge the "java impurities" that have been a > foundation of the language for 15 years—although you may better invest your > own time by switching to another language that's already closer to what you > expect. > > But calling people pigs when they disagree with you is not what I'd call > reasonable criticism. > > > I am not in the apex or any emotional trend; it does not interest me. > > Oh that's exactly the impression you've left so far.
  105249
April 11, 2019 17:41 mo.mu.wss@gmail.com ("M. W. Moe")
@Robert Hickman

yes somehow that's a valid conclusion; however, I can walk and talk; it
does not
bother me at all; I like distractions.

You have a nice day.

On Thu, Apr 11, 2019 at 9:38 AM Robert Hickman <robehickman@gmail.com>
wrote:

> @M. W. Moe If you don't like the java-isms you can ignore them to a > large extent, which I do. However in doing so you're going against the > grain and will end up writing a lot of stuff yourself. I do find it > weird how PHP has morphed so drastically from it's origins and also > wander why. If people wanted a Java-esque language, why not use Java > in the first place? > > This discussion is off topic. > > On Thu, 11 Apr 2019 at 17:15, Benjamin Morel morel@gmail.com> > wrote: > > > > > why? if voicing reasonable criticisms is bothering you; then you should > > do something else in life; > > > because engineering is built on this `very` concept; > > > > You're very welcome to challenge the "java impurities" that have been a > > foundation of the language for 15 years—although you may better invest > your > > own time by switching to another language that's already closer to what > you > > expect. > > > > But calling people pigs when they disagree with you is not what I'd call > > reasonable criticism. > > > > > I am not in the apex or any emotional trend; it does not interest me. > > > > Oh that's exactly the impression you've left so far. >
  105250
April 11, 2019 17:48 mo.mu.wss@gmail.com ("M. W. Moe")
@Benjamin Morel

you must certainly have basic comprehension troubles; read me back; it is
public; keep for yourself your
emotional false projections to myself and infantile behaviors to yourself;
I would never dare simply by following
the basic rules of education; maybe english grammar should introduce a
point of `ironism`; would help or not.

You have a good day; thank you.

On Thu, Apr 11, 2019 at 10:41 AM M. W. Moe wss@gmail.com> wrote:

> @Robert Hickman > > yes somehow that's a valid conclusion; however, I can walk and talk; it > does not > bother me at all; I like distractions. > > You have a nice day. > > On Thu, Apr 11, 2019 at 9:38 AM Robert Hickman <robehickman@gmail.com> > wrote: > >> @M. W. Moe If you don't like the java-isms you can ignore them to a >> large extent, which I do. However in doing so you're going against the >> grain and will end up writing a lot of stuff yourself. I do find it >> weird how PHP has morphed so drastically from it's origins and also >> wander why. If people wanted a Java-esque language, why not use Java >> in the first place? >> >> This discussion is off topic. >> >> On Thu, 11 Apr 2019 at 17:15, Benjamin Morel morel@gmail.com> >> wrote: >> > >> > > why? if voicing reasonable criticisms is bothering you; then you >> should >> > do something else in life; >> > > because engineering is built on this `very` concept; >> > >> > You're very welcome to challenge the "java impurities" that have been a >> > foundation of the language for 15 years—although you may better invest >> your >> > own time by switching to another language that's already closer to what >> you >> > expect. >> > >> > But calling people pigs when they disagree with you is not what I'd call >> > reasonable criticism. >> > >> > > I am not in the apex or any emotional trend; it does not interest me.. >> > >> > Oh that's exactly the impression you've left so far. >> >
  105251
April 11, 2019 18:48 mdwheele@ncsu.edu (Dustin Wheeler)
On Thu, Apr 11, 2019 at 1:48 PM M. W. Moe wss@gmail.com> wrote:
> > @Benjamin Morel > > you must certainly have basic comprehension troubles; read me back; it is > public; keep for yourself your > emotional false projections to myself and infantile behaviors to yourself; > I would never dare simply by following > the basic rules of education; maybe english grammar should introduce a > point of `ironism`; would help or not. > > You have a good day; thank you. >
Hello internals, I am ALL for academic discourse and constructive criticism. This value system has gotten many folks far in life and produces a better product, which I know we all want. However, mo.mu.wss@gmail.com's behaviour on this list is not the type of academic discourse or constructive criticism that inspires individuals to contribute and share their knowledge, in my opinion. mo.mu.wss@gmail.com: could you please temper your language to consider that a human is on the receiving end of your comments. Could you keep your comments within the realm of the RFC discussion-at-hand and away from personal or hyperbolic illustrative language? This RFC is really straight-forward and really, really well documented, prepared and presented. I perceive your hyperbole as a disrespect to the time of contributors to the project and to this thread. Please, temper your language. I hesitate to single you out (as there are other non-ideal behaviours; certainly on this list, but particularly in this thread), but in my opinion, you are the individual with the power to bring us back to a productive discussion. Thanks! -Dustin -- Dustin Wheeler | Software Developer NC State University mdwheele@ncsu.edu "If you don't know where you're going, it's easy to iteratively not get there."
  105243
April 11, 2019 15:22 fabacrans@gmail.com (Fabien S)
Thanks a lot for all your efforts Nikita.

I really like the Haskell `\($x)` syntax, could someone confirm if it would possible to drop the parenthesis (like `\$x`) if we have one argument ?

Thanks in advance, regards
  105245
April 11, 2019 15:53 mo.mu.wss@gmail.com ("M. W. Moe")
@Fabien S

yes, I think you could remove decoration; but still lambda capture process
must
be clarified i.e iterating your ruleset; you don't want to capture every
scope variables.



On Thu, Apr 11, 2019 at 8:22 AM Fabien S <fabacrans@gmail.com> wrote:

> Thanks a lot for all your efforts Nikita. > > I really like the Haskell `\($x)` syntax, could someone confirm if it > would possible to drop the parenthesis (like `\$x`) if we have one argument > ? > > Thanks in advance, regards
  105262
April 12, 2019 14:46 theodorejb@outlook.com (Theodore Brown)
On Thursday, April 11, 2019 at 10:22 AM Fabien S <fabacrans@gmail.com> wrote:

> I really like the Haskell `\($x)` syntax, could someone confirm if > it would possible to drop the parenthesis (like `\$x`) if we have > one argument ?
The RFC says this syntax is ambiguous without the parentheses, since the `\` may also be part of a fully qualified type name. [1] I'm not sure whether it would work if the single parameter isn't typed. I like the Haskell syntax as well, but I'd also be okay with the `fn` keyword if that's what others prefer. [1]: https://wiki.php.net/rfc/arrow_functions_v2#miscellaneous
  105263
April 12, 2019 15:26 fabacrans@gmail.com (Fabien S)
> On 12 Apr 2019, at 16:46, Theodore Brown <theodorejb@outlook.com> wrote: > > On Thursday, April 11, 2019 at 10:22 AM Fabien S <fabacrans@gmail.com> wrote: > >> I really like the Haskell `\($x)` syntax, could someone confirm if >> it would possible to drop the parenthesis (like `\$x`) if we have >> one argument ? > > The RFC says this syntax is ambiguous without the parentheses, since > the `\` may also be part of a fully qualified type name. [1] > > I'm not sure whether it would work if the single parameter isn't typed. > > I like the Haskell syntax as well, but I'd also be okay with the `fn` > keyword if that's what others prefer. > > [1]: https://wiki.php.net/rfc/arrow_functions_v2#miscellaneous
Thanks for the clarification, I should have been more specific but I saw you used `\$x` in your previous message and I was wondering if this syntax is unambiguous. Basically: ```php \$x => $x + 1; // One (not typed) argument, no parenthesis needed \(int $x) => $x + 1; // Typed, parenthesis needed \($x, $y) => $x + $y; // Multiple arguments, parenthesis needed ``` I don't think it's really important but it would be pretty handy syntax in my humble opinion.
  105264
April 12, 2019 15:40 joshdifabio@gmail.com (Josh Di Fabio)
On Fri, Apr 12, 2019 at 4:27 PM Fabien S <fabacrans@gmail.com> wrote:
> > > > On 12 Apr 2019, at 16:46, Theodore Brown <theodorejb@outlook.com> wrote: > > > > On Thursday, April 11, 2019 at 10:22 AM Fabien S <fabacrans@gmail.com> wrote: > > > >> I really like the Haskell `\($x)` syntax, could someone confirm if > >> it would possible to drop the parenthesis (like `\$x`) if we have > >> one argument ? > > > > The RFC says this syntax is ambiguous without the parentheses, since > > the `\` may also be part of a fully qualified type name. [1] > > > > I'm not sure whether it would work if the single parameter isn't typed. > > > > I like the Haskell syntax as well, but I'd also be okay with the `fn` > > keyword if that's what others prefer. > > > > [1]: https://wiki.php.net/rfc/arrow_functions_v2#miscellaneous > > > Thanks for the clarification, I should have been more specific but I saw you used `\$x` in your previous message and I was wondering if this syntax is unambiguous. > > Basically: > > ```php > \$x => $x + 1; // One (not typed) argument, no parenthesis needed > \(int $x) => $x + 1; // Typed, parenthesis needed > \($x, $y) => $x + $y; // Multiple arguments, parenthesis needed > ``` > > I don't think it's really important but it would be pretty handy syntax in my humble opinion.
Agreed. Arrow functions work the same way in TypeScript I think (parens are required for typed parameters).
> -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
  105224
April 10, 2019 20:56 bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)
Den 2019-04-10 kl. 10:39, skrev Rowan Collins:
> On Tue, 9 Apr 2019 at 11:20, Nikita Popov ppv@gmail.com> wrote: > >> The ==> syntax is the other one I implemented ( >> https://github.com/php/php-src/pull/3945). The implementation is based on >> lexer lookahead, which is ugly but still manageable. I haven't seen much >> support for this variant in this discussion though. And of course, if >> there's no strong preference for ==>, I'd rather go with the variant that >> is easier for us (and all 3rd party tooling) to support from a technical >> perspective. >> > > I'd just like to amplify this mention of 3rd party tooling: if we go with > something which requires complex lexer/parser rules, then every editor, > IDE, and static analysis tool will need to also work with that syntax. > > For those saying they "slightly prefer" ==> please ask yourself, do you > prefer it enough to add complexity to every tool that wants to process PHP > source code? > > Regards, Hi,
Could then the \($x) syntax be a good compromise between readability & implementation? It also has the advantage of having less BC impact, since the fn keyword must be a full keyword according to RFC. As a side note I'm thinking on if the Hacklang implementation could shed some light on tooling issues that they got, due to their implementation of the ==> syntax. r//Björn L
  105228
April 10, 2019 23:43 rowan.collins@gmail.com (Rowan Collins)
On 10 April 2019 21:56:41 BST, "Björn Larsson" larsson@telia.com> wrote:
>Could then the \($x) syntax be a good compromise between >readability & implementation?
Personally, I don't find it "more readable"; on the one hand, it's one character shorter; on the other, it stands out less from everything else. My personal bias against it is that I'm too used to reading \ as "escape", so every time I see examples my first reaction is "what does an escaped parenthesis mean?" I'm sure I'd get used to it, but I prefer "fn" because it more immediately makes me think "function". Regards, -- Rowan Collins [IMSoP]
  105234
April 11, 2019 08:45 robehickman@gmail.com (Robert Hickman)
On Thu, 11 Apr 2019 at 00:43, Rowan Collins collins@gmail.com> wrote:
> > On 10 April 2019 21:56:41 BST, "Björn Larsson" larsson@telia.com> wrote: > >Could then the \($x) syntax be a good compromise between > >readability & implementation? >
This syntax does make sense to me, although only as I've seen it before in Haskell, which does something similar: https://wiki.haskell.org/Anonymous_function I think that people will get used to whatever becomes common.