Re: [RFC]Discuss] Syntax for Arrow Functions

From: Date: Sun, 18 Jun 2017 19:44: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-99542@lists.php.net to get a copy of this message
Sorry, I wasn’t aware of that. What do you think of the Ruby/Rust style syntax that Levi proposed a while back? $someDict ->map(|$v| $v * 2) ->filter(|$v| $v % 3); This one has a few advantages: 1. It has syntax (a lot of) developers are already familiar with 2. It has no ambiguities and is fully backward compatible 3. It’s the shortest of all options available (two | characters and one space) > On 18 Jun 2017, at 20:48, Rasmus Schultz <rasmus@mindplay.dk> wrote: > > 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 > <mailto: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 > > <mailto: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 > > <mailto: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 > >>> <mailto: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> < > >> http://www.php.net/unsub.php > >> <http://www.php.net/unsub.php>> > >> > >

« previous php.internals (#99542) next »