Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104715
MIME-Version: 1.0
References: <CAF+90c9YZcrquGfS4h3x1a+codkCFLarAThsOXcN69RCTvbAFA@mail.gmail.com>
 <CALKiJKqCJys2CRFtLPzPO07vsS123z9Bw-meOad0tL7Gd8rf1g@mail.gmail.com>
 <CAG9XoMTTmpr47b7nE3XRUehgzAgKG9Bask7Fhu6v=b0dT7SgRQ@mail.gmail.com> <CALKiJKpFSUsZY0xM8aSR2BVwe7v0pJxZQ_y-XnHnDfVrtwcvgA@mail.gmail.com>
In-Reply-To: <CALKiJKpFSUsZY0xM8aSR2BVwe7v0pJxZQ_y-XnHnDfVrtwcvgA@mail.gmail.com>
Date: Thu, 14 Mar 2019 16:09:58 +0100
Message-ID: <CAG9XoMT+r7GxMeVO6zh9Vr2JwMbqdE2DiSLLoUxuH0pavah4fA@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000008665ff05840f516b"
Subject: Re: [PHP-DEV] [RFC] Arrow functions / short closures
From: benjamin.morel@gmail.com (Benjamin Morel)

--0000000000008665ff05840f516b
Content-Type: text/plain; charset="UTF-8"

>
> The problem, as I understand it, is not avoiding ambiguity, it's avoiding
> lookahead.


You're right, I was only thinking about resolving the ambiguity with array
keys. It's too bad if the parser implementation considerations take
precedence over the purity of the language, but I can understand the
maintenance nightmare that people are trying to avoid here.

Something else that crosses my mind, is: what prevents us from using the
same syntax as ES6:

($x) => $x * $y

But to prevent any ambiguity, forbid array keys from being enclosed with
parenthese? For example, the following would be considered an array
containing a closure:

[ ($foo) => "bar" ]

And the following would just become a syntax error:

[ ("foo") => "bar" ]

Would that solve the parser problem? BC-wise, I don't think this would be
much of a problem: I have yet to see array keys enclosed with parentheses
in PHP codebases.


On Thu, 14 Mar 2019 at 15:54, Rowan Collins <rowan.collins@gmail.com> wrote:

> On Thu, 14 Mar 2019 at 14:12, Benjamin Morel <benjamin.morel@gmail.com>
> wrote:
>
> > This makes me thinking, has this syntax been considered?
> >
> > ($x) => { $x * $y }
> >
> > Nested:
> >
> > ($x) => { ($y) => { $x * $y } }
> >
>
>
> Wouldn't this have all the same parser problems as the RFC discusses?
>
> The problem, as I understand it, is not avoiding ambiguity, it's avoiding
> lookahead. If you write:
>
> $foo = [ ($x) => { $x } ];
> $bar = [ ($x) => $x ];
>
> The parser has already consumed " [ ($x) =>" before it can decide if each
> ($x) is an array key or a closure signature. It's parseable, but only using
> one of the workarounds described in the RFC.
>
> If I'm understanding the RFC correctly, the only way to avoid that is to
> have closures *start* differently from other valid constructs, because then
> the parser doesn't need to recurse / backtrack / etc.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>

--0000000000008665ff05840f516b--