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

This is only part of a thread. view whole thread
  105187
April 9, 2019 22:29 webdevxp.com@gmail.com (Kosit Supanyo)
Hi internals,

This is my first write to this list but I've been followed
your discussions quite a while ago. For a brief introduction,
my name is Kosit, I'm a programmer from Thailand and I've been using
PHP since version 3 (for a short period before moving to PHP4).

I'm a fan of `fn` syntax and OK to go with it but I would like to
propose some extended syntax & behavior about binding.

What if we can omit the `use` keyword at all and use only
second parentheses for variable & reference binding
and make the presence of second parentheses turn off implicit variable
binding.

    $a = 0;
    $f1 = fn(): int => $a;
    $b = 0;
    $f2 = fn(): int () => $b;

equivalent to

    $a = 0;
    $f1 = function () use ($a) { return $a; };
    $b = 0;
    $f2 = function () { return $b; };

And what if we can omit parentheses at all if fn has no parameters.

    $f = fn => $this->doSomethingWithAB($a, $b);
    $multiStmtBody = fn {
        // ...
    };

When people want to import references (and addtional variables)
they have to do it explicitly like before but without `use` keyword.

    $f = fn($y): array (&$arr, $x) => $this->doSomethingWithArrAndXY($arr,
$x, $y);

equivalent to

    $f = function ($y): array use (&$arr, $x) {
        return $this->doSomethingWithArrAndXY($arr, $x, $y);
    };

Second parens without `use` keyword may be ugly but can be seen as
an abbreviation of old closure syntax.

This can eliminate possible problems of reference binding (switching) syntax
described in the RFC that may cause undesired behavior and performance
problem
because `use (&)` will make all variables by-reference bound.

Summary:

1. No `use` keyword for binding.
2. The presence of second parentheses will turn off implicit binding.
3. Can omit parentheses if fn has no parameters.

I apologize in advance for my bad English
but I hope my idea can be taken into consideration
or at least can be transformed into another useful idea.

Regards,
Kosit

On Mon, Apr 8, 2019 at 9:07 PM Nikita Popov ppv@gmail.com> wrote:
> > 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
  105188
April 10, 2019 00:33 mo.mu.wss@gmail.com ("M. W. Moe")
Hello,

for now what I see is a bit of everything:
- adding a contextual keyword/alias to function
- enforce by reference
- a lack of coherence

too mockups (I like the arrow idea but won't ever replace `use`
functionalities)

"keeping the unnecessary  arrow"

class bar
{
   public fn foo(int $x, int $y)
   {
      return fn($x) [&$y] => {
         $x * $y;
      };
   }
}

"aliasing function keyword to fn; aliasing use keyword  with brackets
syntax"

class bar
{
   public fn foo(int $x, int $y)
   {
      return fn($x) [&$y] { $x * $y; }
   }
}


On Tue, Apr 9, 2019 at 3:29 PM Kosit Supanyo com@gmail.com> wrote:

> Hi internals, > > This is my first write to this list but I've been followed > your discussions quite a while ago. For a brief introduction, > my name is Kosit, I'm a programmer from Thailand and I've been using > PHP since version 3 (for a short period before moving to PHP4). > > I'm a fan of `fn` syntax and OK to go with it but I would like to > propose some extended syntax & behavior about binding. > > What if we can omit the `use` keyword at all and use only > second parentheses for variable & reference binding > and make the presence of second parentheses turn off implicit variable > binding. > > $a = 0; > $f1 = fn(): int => $a; > $b = 0; > $f2 = fn(): int () => $b; > > equivalent to > > $a = 0; > $f1 = function () use ($a) { return $a; }; > $b = 0; > $f2 = function () { return $b; }; > > And what if we can omit parentheses at all if fn has no parameters. > > $f = fn => $this->doSomethingWithAB($a, $b); > $multiStmtBody = fn { > // ... > }; > > When people want to import references (and addtional variables) > they have to do it explicitly like before but without `use` keyword. > > $f = fn($y): array (&$arr, $x) => $this->doSomethingWithArrAndXY($arr, > $x, $y); > > equivalent to > > $f = function ($y): array use (&$arr, $x) { > return $this->doSomethingWithArrAndXY($arr, $x, $y); > }; > > Second parens without `use` keyword may be ugly but can be seen as > an abbreviation of old closure syntax. > > This can eliminate possible problems of reference binding (switching) > syntax > described in the RFC that may cause undesired behavior and performance > problem > because `use (&)` will make all variables by-reference bound. > > Summary: > > 1. No `use` keyword for binding. > 2. The presence of second parentheses will turn off implicit binding. > 3. Can omit parentheses if fn has no parameters. > > I apologize in advance for my bad English > but I hope my idea can be taken into consideration > or at least can be transformed into another useful idea. > > Regards, > Kosit > > On Mon, Apr 8, 2019 at 9:07 PM Nikita Popov ppv@gmail.com> wrote: > > > > 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 >
  105189
April 10, 2019 00:50 mo.mu.wss@gmail.com ("M. W. Moe")
and maybe one day if public, protected, private, interface, abstract i.e
java impurities are finally removed:

class bar
{
   owned var $m_a : float = 0.0;
         var $b : object = null;

   fn foo(int $x, int $y) : int
   { return fn($x) [&$y] { $x * $y; }; }

   owned fn bar() : void
   { return; }
}

On Tue, Apr 9, 2019 at 5:33 PM M. W. Moe wss@gmail.com> wrote:

> Hello, > > for now what I see is a bit of everything: > - adding a contextual keyword/alias to function > - enforce by reference > - a lack of coherence > > too mockups (I like the arrow idea but won't ever replace `use` > functionalities) > > "keeping the unnecessary arrow" > > class bar > { > public fn foo(int $x, int $y) > { > return fn($x) [&$y] => { > $x * $y; > }; > } > } > > "aliasing function keyword to fn; aliasing use keyword with brackets > syntax" > > class bar > { > public fn foo(int $x, int $y) > { > return fn($x) [&$y] { $x * $y; } > } > } > > > On Tue, Apr 9, 2019 at 3:29 PM Kosit Supanyo com@gmail.com> > wrote: > >> Hi internals, >> >> This is my first write to this list but I've been followed >> your discussions quite a while ago. For a brief introduction, >> my name is Kosit, I'm a programmer from Thailand and I've been using >> PHP since version 3 (for a short period before moving to PHP4). >> >> I'm a fan of `fn` syntax and OK to go with it but I would like to >> propose some extended syntax & behavior about binding. >> >> What if we can omit the `use` keyword at all and use only >> second parentheses for variable & reference binding >> and make the presence of second parentheses turn off implicit variable >> binding. >> >> $a = 0; >> $f1 = fn(): int => $a; >> $b = 0; >> $f2 = fn(): int () => $b; >> >> equivalent to >> >> $a = 0; >> $f1 = function () use ($a) { return $a; }; >> $b = 0; >> $f2 = function () { return $b; }; >> >> And what if we can omit parentheses at all if fn has no parameters. >> >> $f = fn => $this->doSomethingWithAB($a, $b); >> $multiStmtBody = fn { >> // ... >> }; >> >> When people want to import references (and addtional variables) >> they have to do it explicitly like before but without `use` keyword. >> >> $f = fn($y): array (&$arr, $x) => $this->doSomethingWithArrAndXY($arr, >> $x, $y); >> >> equivalent to >> >> $f = function ($y): array use (&$arr, $x) { >> return $this->doSomethingWithArrAndXY($arr, $x, $y); >> }; >> >> Second parens without `use` keyword may be ugly but can be seen as >> an abbreviation of old closure syntax. >> >> This can eliminate possible problems of reference binding (switching) >> syntax >> described in the RFC that may cause undesired behavior and performance >> problem >> because `use (&)` will make all variables by-reference bound. >> >> Summary: >> >> 1. No `use` keyword for binding. >> 2. The presence of second parentheses will turn off implicit binding. >> 3. Can omit parentheses if fn has no parameters. >> >> I apologize in advance for my bad English >> but I hope my idea can be taken into consideration >> or at least can be transformed into another useful idea. >> >> Regards, >> Kosit >> >> On Mon, Apr 8, 2019 at 9:07 PM Nikita Popov ppv@gmail.com> wrote: >> > >> > 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 >> >