Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88418
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.213.53 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAAyV7nEc4c3erQfK+CbkpGGjph8vBUJx46e1=Ruj25872LrcoA@mail.gmail.com>
References: <BLU436-SMTP156E8D7D141A710541FCA0FE2450@phx.gbl>
	<CA+9eiLtfxLNCMra1Xj9PEhAFZB+h903AK1rmWSQAH4SqQm2qCQ@mail.gmail.com>
	<CAL=_i_=wR5e3Bv++pKwMZcBJoF+0tVsXuRHnZYpa4wnq+cBdWg@mail.gmail.com>
	<CA+9eiLtVxiohBkQeDbP_aDtTdwQD_8p46gT73bikQTKKi8rHSQ@mail.gmail.com>
	<BLU436-SMTP1607EC07C73BB9E5D5AB95EE2450@phx.gbl>
	<CA+9eiLv3ge6Ur76DS8kjW2ZFV3ciLLhbDfvWXKu3FeR=e1CLdw@mail.gmail.com>
	<CAAyV7nEc4c3erQfK+CbkpGGjph8vBUJx46e1=Ruj25872LrcoA@mail.gmail.com>
Date: Tue, 22 Sep 2015 22:19:27 +0300
Message-ID: <CA+9eiLuwyO_EgaDiaxwf+zVdNSUD5KBHUKkK4db+TcM5ZVgY2w@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: Bob Weinand <bobwei9@hotmail.com>, Joe Watkins <pthreads@pthreads.org>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11415a8e6c2cec05205ae02c
Subject: Re: [PHP-DEV] [RFC] [VOTE] Short Closures
From: dmitry@zend.com (Dmitry Stogov)

--001a11415a8e6c2cec05205ae02c
Content-Type: text/plain; charset=UTF-8

On Tue, Sep 22, 2015 at 9:20 PM, Anthony Ferrara <ircmaxell@gmail.com>
wrote:

> Dmitry,
>
> On Tue, Sep 22, 2015 at 2:05 PM, Dmitry Stogov <dmitry@zend.com> wrote:
> > On Tue, Sep 22, 2015 at 7:01 PM, Bob Weinand <bobwei9@hotmail.com>
> wrote:
> >
> >>
> >> > Am 22.09.2015 um 17:36 schrieb Dmitry Stogov <dmitry@zend.com>:
> >> >
> >> > On Tue, Sep 22, 2015 at 4:54 PM, Joe Watkins <pthreads@pthreads.org>
> >> wrote:
> >> >
> >> >> I'd really like to understand what you're trying to say there Dmitry,
> >> but
> >> >> I don't get it.
> >> >>
> >> >> What is your example function trying to show ?
> >> >>
> >> >> As it mentions in the RFC, vars in short closure are by-value, so I
> >> can't
> >> >> see what side effects you might be thinking of ?
> >> >>
> >> >
> >> > It's clear to me that foo() will return NULL, but how many warnings
> about
> >> > unused variable $y will we get?
> >> >
> >> > Thanks. Dmitry.
> >> >
> >> >
> >> >>
> >> >> Cheers
> >> >> Joe
> >> >>
> >> >> On Tue, Sep 22, 2015 at 9:25 AM, Dmitry Stogov <dmitry@zend.com>
> wrote:
> >> >>
> >> >>> I'm against the magic - "automatically use () all of the (compiled)
> >> >>> variables".
> >> >>> I'm also against compound short closures with curly brackets.
> >> >>> in my opinion they opens too many ambiguous questions.
> >> >>>
> >> >>> function foo() {
> >> >>>  (($x) ~> {$y = 3; return $y + $x;})(5);
> >> >>>  return $y;
> >> >>> }
> >> >>>
> >> >>> also think about nested closures and use of variables from not
> direct
> >> >>> enclosure.
> >> >>>
> >> >>> I'm not sure if we need all "functional programming" features in
> PHP,
> >> but
> >> >>> if we introduce them, lets do it consistently with the existing
> >> language.
> >> >>> I think, this proposal can't be approved without support for type
> >> hinting.
> >> >>>
> >> >>> Thanks. Dmitry.
> >> >>>
> >> >>> On Tue, Sep 22, 2015 at 4:59 AM, Bob Weinand <bobwei9@hotmail.com>
> >> wrote:
> >> >>>
> >> >>>> Hey,
> >> >>>>
> >> >>>> Thanks for all your feedback in the discussion thread!
> >> >>>>
> >> >>>> So, before I start the vote, just two quick notes:
> >> >>>> I've added two notes about the statement syntax and the single
> >> variable
> >> >>>> use.
> >> >>>> Though a few people complained, I'm not switching to the ==>
> operator,
> >> >>> as
> >> >>>> I noticed many people expected typehints to work (they don't due to
> >> >>> parser
> >> >>>> limitations) when they compared to Hack's short Closures. It also
> >> >>> allows us
> >> >>>> to differ syntax-wise [e.g. for typehints] from Hack without
> causing
> >> any
> >> >>>> confusion later. Which should be the smartest choice: Avoid
> conflicts.
> >> >>> (If
> >> >>>> anyone strongly feels against that, he may vote no, but I would
> like
> >> to
> >> >>> not
> >> >>>> bikeshed that in this Vote thread, but leave it free for eventual
> >> actual
> >> >>>> issues.)
> >> >>>>
> >> >>>> Now, the link to the RFC about Short Closures:
> >> >>>> https://wiki.php.net/rfc/short_closures
> >> >>>> or straight ahead to the vote:
> >> >>>> https://wiki.php.net/rfc/short_closures#vote
> >> >>>>
> >> >>>> Thanks,
> >> >>>> Bob
> >>
> >>
> >> Notice: Undefined variable: y in php shell code on line 3
> >>
> >> It just yields exactly one notice about the inexistent $y (as it
> obviously
> >> does not leak through the scope): by-value binding.
> >>
> >> I'm not sure what your issue here is?
> >>
> >
> > The current PHP version emits two warning on similar constructs, and this
> > is explainable because we explicitly "use" $y.
> >
> > $ sapi/cli/php -r 'function foo(){(function($x) use ($y){$y=3; return
> > $y+$x;})(5);return $y;} var_dump(foo());'
> > PHP Notice:  Undefined variable: y in Command line code on line 1
> >
> > PHP Notice:  Undefined variable: y in Command line code on line 1
> >
> > NULL
> >
>
> There's an important distinction here. The explicit `use($y)` triggers
> a notice because you said to use an undefined variable.
>
> function foo() {
>   (($x) ~> {$y = 3; return $y + $x;})(5);
>   return $y;
> }
>
> In this case, there's no practical binding of `$y` at all. The `$y` in
> the scope of the closure is never actually read from before it is
> assigned to. Meaning the variable doesn't need to exist prior to that
> assignment, meaning that it doesn't have to be bound (used), and as
> such shouldn't throw a notice.
>

This is not the way like PHP works and the proposed patch didn't change
this.
It produced warning on "implicit" use.
Now Bob seems to fixed this by hiding the warning.


>
> This becomes a ton easier if we ever move to an explicit CFG+SSA
> compile step. Then, we can see which variables dominate the closure to
> see what needs to be bound vs what doesn't. In this example, converted
> to SSA, you'd see:
>
> function foo() {
>   $y1 = 12;
>   (($x1) ~> {$y2 = 3; return $y2 + $x1;})(5);
>   return $y1;
> }
>
> Hence you can see that `$y2` is truly an independent variable, and
> hence `$y1` never needs to be bound (and hence no notice).
>
> So your case of explicitly using `$y` isn't actually what's happening
> with the closure (at least with respect to userland behavior). Hence
> why the lack of notice exists.
>
> My $0.02 at least,
>

This is interesting, and I also thought about this.
But this is going to be different language with different rules.
Also, this approach can't handle all possible cases in dynamic languages,
where we can't say if variable is used or assigned first.

function foo() {
  $y = 1;
  $f = ($x) ~> {
    for ($i = 0; $i < 2; $i++) {
       if ($x) {
         $y = 5;
       } else {
         echo $y
       }
   };
  $f(0);
  $f(1);
}

Your approach won't be able to determine if $y in short closure is local
variable or from function foo().
Anyway, this is not related to Bob's proposal.

Thanks. Dmitry.


>
> Anthony
>

--001a11415a8e6c2cec05205ae02c--