Re: [RFC]Discuss] Syntax for Arrow Functions

From: Date: Sun, 18 Jun 2017 18:48:58 +0000
Subject: Re: [RFC]Discuss] Syntax for Arrow Functions
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20  Groups: php.internals 
Request: Send a blank email to internals+get-99541@lists.php.net to get a copy of this message
I understand it's not ambiguous to the parser if it's a keyword. I was referring to the visual ambiguity - the fn($x) part of the syntax is indistinguishable from a function-call. On Sun, Jun 18, 2017 at 8:42 PM, Ilija Tovilo <ilija.tovilo@me.com> wrote: > > I don't agree that the fn keyword solves the ambiguity problem - it looks > > exactly like a function call. > > > Right. But it does solve the ambiguity if fn is a keyword which > is what > the RFC suggests. > > > > On 18 Jun 2017, at 18:40, Rasmus Schultz <rasmus@mindplay.dk> wrote: > > > > I don't agree that the fn keyword solves the ambiguity problem - it looks > > exactly like a function call. > > > > As for the backslash, my honest reaction is, ugh, please, no more > > backslashes - PHP (and every other language) uses backslashes for > escaping > > in strings, it already looks pretty awkward in namespaces, this won't > help. > > > > > > On Sun, Jun 18, 2017 at 12:58 PM, Ilija Tovilo <ilija.tovilo@me.com> > wrote: > > > >> The backslash has actually been one of the earlier options if I remember > >> correctly. > >> I definitely prefer the fn keyword as it’s only one > >> character more but > >> adds a better visual hint to the arrow function. > >> > >> I’m also not sure why we’d choose a different arrow > >> (==> or ~>) when > >> the ambiguity is solved through either a the backslash or the > >> fn > keyword. > >> > >> > >>> On 15 Jun 2017, at 17:00, Björn Larsson <bjorn.x.larsson@telia.com> > >> wrote: > >>> > >>> Den 2017-06-15 kl. 15:34, skrev Fleshgrinder: > >>> > >>>> On 6/15/2017 3:29 PM, Björn Larsson wrote: > >>>>> 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 > >>>>> > >>>> On Reddit someone proposed the following syntax: > >>>> > >>>> \() => echo 'Hello, World' > >>>> > >>>> It is used by Haskell if I remember correctly and should not be > >>>> ambiguous since ( is not allowed in names of > >>>> classes or functions. > It > >>>> actually aligns well with functions that are called with a > >>>> fully-qualified name (e.g. > >>>> \printf('')). > >>>> > >>>> Not sure if it would still require hacks though. > >>>> > >>> So applying that one on Sara's example becomes with some > >>> options for the arrow: > >>> 8. $someDict->map(\($v) => $v * 2)->filter(\($v) => $v % 3); > >>> 9. $someDict->map(\($v) ==> $v * 2)->filter(\($v) ==> $v % 3); > >>> 10. $someDict->map(\($v) ~> $v * 2)->filter(\($v) ~> $v % 3); > >>> > >>> Interesting :) > >>> > >>> r//Björn > >>> > >>> -- > >>> PHP Internals - PHP Runtime Development Mailing List > >>> To unsubscribe, visit: > >>> http://www.php.net/unsub.php < > >> http://www.php.net/unsub.php> > >> > >

« previous php.internals (#99541) next »