Re: [RFC]Discuss] Syntax for Arrow Functions

On Fri, Jun 9, 2017 at 4:43 PM, Rowan Collins <rowan.collins@gmail.com> wrote: > On 9 June 2017 21:00:48 BST, Niklas Keller <me@kelunik.com> wrote: >>2017-06-09 15:44 GMT+02:00 Sara Golemon <pollita@php.net>: >> >>> 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. >> >> >>Another possible syntax (dunno whether this has already been suggested >>on-list): >> >>$function = { $x => 2 * $x }; >>$function = { ($x) => 2 * $x }; >>$function = | $x => 2 * $x |; >>$function = | ($x) => 2 * $x |; >> >>Nikita and Levi prefer it with parenthesis, I prefer it without, >>because I >>think it's unnecessary clutter. > > I already suggested the brace version, and Levi said it would conflict in the parser: > https://externals.io/thread/911#email-15331 I don't know enough > about parsing to comment on what workarounds would be possible. It ends up not conflicting; when at top level you can keep existing behavior and otherwise make it a closure. Given that creating a closure without assigning it to variable or passing it to a function is useless this is fine.