Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99528
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain telia.com from 81.236.60.155 cause and error)
To: Sara Golemon <pollita@php.net>
Cc: Rowan Collins <rowan.collins@gmail.com>,
 PHP internals <internals@lists.php.net>
References: <CAFMT4Npoo_ZrRk-kk4C6KHYEtV93pU7Wmh0FhaPi6Z-9qkObaQ@mail.gmail.com>
 <CADqTB_hWrhBBQetfp=-LFR=OYALHwhs=mYd3vPQOYGGng26UsA@mail.gmail.com>
 <4077c099-2247-c3c1-7dee-02a6b25f8586@fleshgrinder.com>
 <CAObuZdtHXp=icU_aB8dWyjbzW-yZ0sSTW6ObmEsxTuvR679-Fw@mail.gmail.com>
 <CAObuZdvck_w5iEeH5Sz23pDS1T727gtN7pn8XCiPWBvqVWR5Ag@mail.gmail.com>
 <CAObuZdvYX8Yr4KQnzJNeF8CSJVwpxuDevV+6=w_J5J9gx5R8HQ@mail.gmail.com>
 <559b73f7-c40f-e593-f0e1-51b56210d7cb@telia.com>
 <2053A608-6B66-42FB-A6D7-7CC64E94DA6A@koalephant.com>
 <4FBDE643-1EBC-485A-A39F-7E28C5D4807A@koalephant.com>
 <e1c608a0-d046-d3a8-a360-d33c3aa75666@telia.com>
 <034f3ebf-95b8-a7cf-1279-77c7cf0424d7@gmail.com>
 <46143e7c-ef75-7c05-eaa9-98c8f3b405f1@telia.com>
 <CAESVnVrLG4nRrcm7MYAQutb4umLq=FkGo2CWHYqHw+bYo72Bsg@mail.gmail.com>
 <d45a3327-59d4-5c93-1425-70cc2d08a87e@telia.com>
 <CAESVnVpQtLXhKnUn2EE4s7rZn11r5Kpj2zOSOKRCWFaxaeOrjg@mail.gmail.com>
 <b1105f90-91e9-e61a-b96b-5078c337ab5c@telia.com>
Message-ID: <b47c4379-109c-c289-1077-b42ea40fe19f@telia.com>
Date: Thu, 15 Jun 2017 15:29:42 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.2.0
MIME-Version: 1.0
In-Reply-To: <b1105f90-91e9-e61a-b96b-5078c337ab5c@telia.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: sv
Subject: Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions
From: bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)

Den 2017-06-10 kl. 10:05, skrev Björn Larsson:

> Den 2017-06-09 kl. 15:44, skrev Sara Golemon:
>> On Fri, Jun 9, 2017 at 7:23 AM, Björn Larsson 
>> <bjorn.x.larsson@telia.com> wrote:
>>> If I take the liberty in using the example above on our option list:
>>> 1. $someDict->map(fn($v) => $v * 2)->filter(fn($v) => $v % 3);
>>> 2. $someDict->map(function($v) => $v * 2)->filter(function($v) => $v 
>>> % 3);
>>> 3. $someDict->map($v ==> $v * 2)->filter($v ==> $v % 3);
>>> 4. $someDict->map(($v) => $v * 2)->filter(($v) => $v % 3);        //
>>> Ambiguous
>>> 5. $someDict->map([]($v) => $v * 2)->filter([]($v) => $v % 3);
>>>
>>> Old proposals:
>>> 6. $someDict->map($v ~> $v * 2)->filter($v ~> $v % 3);
>>> 7. $someDict->map(lambda($v) => $v * 2)->filter(lambda($v) => $v % 3);
>>>
>> Something else which really pops in these examples is the effect of
>> not needing to use parentheses when embedding a single-arg short
>> lambda.   3 and 6 in your list read cleaner to me (due to the lack of
>> parenthesis clutter).  Sadly ~> has the same hacky implementation
>> issues as ==>, but I think that shows a little bit of why the HackLang
>> team decided the messy lexer was worth the clearer syntax.
>>
> Yup, totally agree on that one. It improves redability and when you have
> more parameters I find the parenthesis less disturbing like.
> - $someDict->map(($v, $y) ==> $v * 2 + $y)->filter(($v, $y) ==> $v % 3 
> - $y);
>
> Btw, do you think there is a way around the hacky implementation, given
> that PHP now has a new and shining engine?
>
> r//Björn
>
Seems like the constraints on this feature makes it hard to fly, i.e.
1. Not a hackish implementation
2. Non ambiguous syntax
3. Easy to parse & use syntax for the human

HackLang then prioritised 2 & 3 making the end-users happy, but
had to sacrifise a clean implementation. Any clue if this was a one-
time effort once it was done or something with a lot of drawbacks
in terms of maintenance, performance, evolution etc?

r//Björn