Re: [RFC]Discuss] Syntax for Arrow Functions

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