"Andrea Faulds" wrote in message news:19.45.38491.677d4...@pb1.pair.com...
Hi David,
David Rodrigues wrote:
Hello folks!
I just not understand why "function" should be abbreviated. It's about
"how
less character better"? I don't see it too much on PHP. I guess that is
more simple keep what
> And then there's the extra typing and visual space taken up, which is not
> something to dismiss entirely. Also, as someone else mentioned this syntax
> *seems* like it would support nesting. Compare the following:
>
> $x = function($a) => function($b) => function($c) => $a * $b * $c;
> $y = fn(
2017-02-04 21:49 GMT+01:00 Larry Garfield :
> On 02/03/2017 11:53 AM, Levi Morrison wrote:
>
>>
>> Thanks to everyone who has participated in the discussion thus far.
>>> Primarily the feedback has been directed at the `fn` keyword. Let me
>>> provide two benefits and drawbacks of using `fn` as a
On 02/03/2017 11:53 AM, Levi Morrison wrote:
Thanks to everyone who has participated in the discussion thus far.
Primarily the feedback has been directed at the `fn` keyword. Let me
provide two benefits and drawbacks of using `fn` as a keyword:
1. `fn` is searchable in search engines and in
On Sat, Feb 4, 2017 at 4:14 PM, Yasuo Ohgaki wrote:
>
>> fn(params) => expr
>> |params| => expr
>>
>> I look forward to more discussion!
>>
>
> It's unfortunate we cannot have HHVM/Hack syntax now
> https://docs.hhvm.com/hack/lambdas/introduction
>
> but both
> fn(params) => expr
> |param
Hi Levi,
On Sat, Feb 4, 2017 at 2:53 AM, Levi Morrison wrote:
> One more thing: I'd like to re-emphasize that the syntax that
> JavaScript uses and the one that HHVM/Hack uses are ambiguous in the
> current class of our grammar. The following will not work unless we
> move to a more powerful gra
Den 2017-02-03 kl. 21:46, skrev Levi Morrison:
On Fri, Feb 3, 2017 at 1:37 PM, Niklas Keller wrote:
2017-02-03 21:23 GMT+01:00 Levi Morrison :
On Fri, Feb 3, 2017 at 12:18 PM, Andrea Faulds wrote:
Hi David,
David Rodrigues wrote:
Hello folks!
I just not understand why "function" should be
On 03.02.2017 at 18:53, Levi Morrison wrote:
> One more thing: I'd like to re-emphasize that the syntax that
> JavaScript uses and the one that HHVM/Hack uses are ambiguous in the
> current class of our grammar. The following will not work unless we
> move to a more powerful grammar and parser cla
2017-02-03 23:26 GMT+01:00 Michael Morris :
> On Fri, Feb 3, 2017 at 3:37 PM, Niklas Keller wrote:
> >
> >
> > There are more drawbacks to that syntax like no parameters looking pretty
> > weird: || =>
> >
> >
> I can't think of a valid example of an arrow function without any arguments
> at all.
On 2/3/2017 11:26 PM, Michael Morris wrote:
> On Fri, Feb 3, 2017 at 3:37 PM, Niklas Keller wrote:
>>
>>
>> There are more drawbacks to that syntax like no parameters looking pretty
>> weird: || =>
>>
>>
> I can't think of a valid example of an arrow function without any arguments
> at all. These
On Fri, Feb 3, 2017 at 3:37 PM, Niklas Keller wrote:
>
>
> There are more drawbacks to that syntax like no parameters looking pretty
> weird: || =>
>
>
I can't think of a valid example of an arrow function without any arguments
at all. These functions are very simple iterators to plug into things
On Fri, Feb 3, 2017 at 3:34 PM, wrote:
> I like the suggested syntax. The only drawback I see is that it inhibits
> the future addition of union types for closures:
>
> |int | float $x| => $x
>
> Adding parentheses of course resolves the issue but looks a bit awkward:
>
> |(int | float) $
On Fri, Feb 3, 2017 at 1:37 PM, Niklas Keller wrote:
> 2017-02-03 21:23 GMT+01:00 Levi Morrison :
>>
>> On Fri, Feb 3, 2017 at 12:18 PM, Andrea Faulds wrote:
>> > Hi David,
>> >
>> > David Rodrigues wrote:
>> >>
>> >> Hello folks!
>> >> I just not understand why "function" should be abbreviated.
2017-02-03 21:23 GMT+01:00 Levi Morrison :
> On Fri, Feb 3, 2017 at 12:18 PM, Andrea Faulds wrote:
> > Hi David,
> >
> > David Rodrigues wrote:
> >>
> >> Hello folks!
> >> I just not understand why "function" should be abbreviated. It's about
> >> "how
> >> less character better"? I don't see it
I like the suggested syntax. The only drawback I see is that it inhibits the
future addition of union types for closures:
|int | float $x| => $x
Adding parentheses of course resolves the issue but looks a bit awkward:
|(int | float) $x| => $x
Apart from that I have nothing to complain
On Fri, Feb 3, 2017 at 12:18 PM, Andrea Faulds wrote:
> Hi David,
>
> David Rodrigues wrote:
>>
>> Hello folks!
>> I just not understand why "function" should be abbreviated. It's about
>> "how
>> less character better"? I don't see it too much on PHP. I guess that is
>> more simple keep what exis
Hi David,
David Rodrigues wrote:
Hello folks!
I just not understand why "function" should be abbreviated. It's about "how
less character better"? I don't see it too much on PHP. I guess that is
more simple keep what exists current "function", that all knows about (that
should be better than the
On Fri, Feb 3, 2017 at 11:46 AM, David Rodrigues wrote:
> Or even, I too don't know why just ($x) => is an issue. There some possible
> conflict why that?
Yes, this conflicts with existing syntax. The following code snippets
are valid today:
[($x) => $x + $y]
yield ($x) => $x + $y
There
Hello folks!
I just not understand why "function" should be abbreviated. It's about "how
less character better"? I don't see it too much on PHP. I guess that is
more simple keep what exists current "function", that all knows about (that
should be better than the next example):
$mapped = array_map(
On Fri, Feb 3, 2017 at 12:53 PM, Levi Morrison wrote:
>
> > To that end, I'd like to gauge interest in a pure syntax based
> > alternative that is similar to Rust and Ruby.
> > Instead of:
> >
> > fn(params) => expr
> >
> > What about:
> >
> > |params| => expr
>
Looks great to me from up
On Fri, Feb 3, 2017 at 10:48 AM, Levi Morrison wrote:
> On Mon, Jan 30, 2017 at 10:55 AM, Levi Morrison wrote:
>> Bob Weinand and I are happy to announce that the [Arrow Functions][1]
>> RFC is moving into the public discussion phase. We have been
>> collaborating on this RFC for many months now
On Mon, Jan 30, 2017 at 10:55 AM, Levi Morrison wrote:
> Bob Weinand and I are happy to announce that the [Arrow Functions][1]
> RFC is moving into the public discussion phase. We have been
> collaborating on this RFC for many months now and finally have a
> proposal we are happy to discuss in the
On Mon, Jan 30, 2017 at 10:55 AM, Levi Morrison wrote:
> Bob Weinand and I are happy to announce that the [Arrow Functions][1]
> RFC is moving into the public discussion phase. We have been
> collaborating on this RFC for many months now and finally have a
> proposal we are happy to discuss in the
On Wed, Feb 1, 2017 at 3:06 PM, Rowan Collins
wrote:
> On 01/02/2017 20:17, Rasmus Lerdorf wrote:
>
>> You probably think of $var as being a local scope variable here,
>> but really it isn't. It is an imported variable that happened to not exist
>> in the outer scope and it was assigned a value i
On 01/02/2017 20:17, Rasmus Lerdorf wrote:
You probably think of $var as being a local scope variable here,
but really it isn't. It is an imported variable that happened to not exist
in the outer scope and it was assigned a value in the inner scope, but that
assignment can't leak back out so it i
On Wed, Feb 1, 2017 at 8:05 AM, Bruce Weirdan wrote:
> On Wed, Feb 01, 2017 at 07:45:50AM -0800, Rasmus Lerdorf wrote:
> > The reason it is feasible to do this for single-expression closures in
> this
> > short form syntax is that you don't typically need a local scope at all
> for
> > these shor
On Wed, Feb 01, 2017 at 07:45:50AM -0800, Rasmus Lerdorf wrote:
> The reason it is feasible to do this for single-expression closures in this
> short form syntax is that you don't typically need a local scope at all for
> these short closures and the syntax doesn't convey the idea that you would
>
On Tue, Jan 31, 2017 at 12:41 PM, Andrea Faulds wrote:
>
> That's the idea. I'd prefer it if auto-capture was not restricted to
> single-expression functions (“arrow functions”). Though arrow functions
> make most sense with auto-capture, it doesn't need to be stricted to them.
This goes against
On 31/01/2017 20:41, Andrea Faulds wrote:
That's the idea. I'd prefer it if auto-capture was not restricted to
single-expression functions (“arrow functions”). Though arrow
functions make most sense with auto-capture, it doesn't need to be
stricted to them.
I respectfully disagree completely
Hi Marc,
Marc Bennewitz wrote:
- Also I like the "use" keyword you have to define your variables
-> Would it be helpful to allow "function () use (*) {}" to inline
all available variables?
I did think of that, but it's not as concise as not having to specify
`use` at all. You could take
Hi,
David Walker wrote:
On Mon, Jan 30, 2017 at 18:12 Andrea Faulds wrote:
Is it necessary to introduce a new keyword, fn?
I think you'd get a similar benefit from:
function($x) => $arr[$x]
Likewise, is it necessary to restrict auto-capture to the => syntax?
Couldn't we allow the foll
On Mon, Jan 30, 2017 at 10:55 AM, Levi Morrison wrote:
> Bob Weinand and I are happy to announce that the [Arrow Functions][1]
> RFC is moving into the public discussion phase. We have been
> collaborating on this RFC for many months now and finally have a
> proposal we are happy to discuss in the
On 31/01/17 05:53, Stephen Reay wrote:
> Hi Andrea, All,
>
>> On 31 Jan 2017, at 08:12, Andrea Faulds wrote:
>>
>> Is it necessary to introduce a new keyword, fn?
>>
>> I think you'd get a similar benefit from:
>>
>>function($x) => $arr[$x]
>>
>> Likewise, is it necessary to restrict auto-capt
Am 31.01.2017 um 05:53 schrieb Stephen Reay:
Hi Andrea, All,
On 31 Jan 2017, at 08:12, Andrea Faulds wrote:
Is it necessary to introduce a new keyword, fn?
I think you'd get a similar benefit from:
function($x) => $arr[$x]
Likewise, is it necessary to restrict auto-capture to the => s
Hi Andrea, All,
> On 31 Jan 2017, at 08:12, Andrea Faulds wrote:
>
> Is it necessary to introduce a new keyword, fn?
>
> I think you'd get a similar benefit from:
>
>function($x) => $arr[$x]
>
> Likewise, is it necessary to restrict auto-capture to the => syntax? Couldn't
> we allow the
On Mon, Jan 30, 2017 at 18:12 Andrea Faulds wrote:
> Hi Levi,
>
> Levi Morrison wrote:
> > Here is an example of an existing closure:
> >
> > function ($x) use ($arr) {
> > return $arr[$x];
> > }
> >
> > This RFC proposes syntax and semantics to simplify this common usage to:
> >
Hi Levi,
Levi Morrison wrote:
Here is an example of an existing closure:
function ($x) use ($arr) {
return $arr[$x];
}
This RFC proposes syntax and semantics to simplify this common usage to:
fn($x) => $arr[$x]
Is it necessary to introduce a new keyword, fn?
I think yo
37 matches
Mail list logo
