On 23 June 2017 19:43:19 BST, Rasmus Schultz wrote:
>Suffice it to say, I understand your arguments and your point of view,
>I
>just don't agree with it
Indeed, as I say, different people want different things from this proposal,
and no syntax is going to suit all of them. I think this is import
I think there is not much point in carrying on this debate.
Suffice it to say, I understand your arguments and your point of view, I
just don't agree with it - if this new feature produces closures, by my
understanding, it's alternate syntax for producing closures, and does not
constitute a new la
On Wed, Jun 21, 2017 at 11:19 PM, Rowan Collins
wrote:
>
> The short form is still constrained to be a single expression, because
> otherwise you can't omit the "return" statement;
For the sake of discussion, Groovy has optional returns where the last
evaluated expression in a closure is returne
On 21/06/2017 15:04, Rasmus Schultz wrote:
> > For me (and I am not alone), this feature is NOT a new syntax for
closures
>
> Regardless of why you want it, that's exactly what it is though -
another way to declare a closure.
>
> Even if it has different semantics, the resulting object is stil
> Once you start getting into multi statement closures, all the weird
syntax elements that are being proposed just make it harder to read and
harder to visually parse.
The same is true for current function syntax. But that's what line-breaks
are for :-)
> Automatically importing variables isn’t “
> For me (and I am not alone), this feature is NOT a new syntax for closures
Regardless of why you want it, that's exactly what it is though - another
way to declare a closure.
Even if it has different semantics, the resulting object is still an
instance of Closure, right?
It should pass type-ch
On 19 June 2017 21:22:53 BST, Rasmus Schultz wrote:
>So what's on the table is a syntax-improved but feature-crippled
>variant of
>closures, not an all-round replacement?
I haven't the time right now to dig out my summary from the mail archives, but
this is one of the fundamental disagreements /
> I just think your example is an exaggeration to what happens in practice.
I think it's an example of what happens with any inconsistent feature in
any language.
On Tue, Jun 20, 2017 at 9:53 AM, Markus Fischer wrote:
> Hello Rasmus,
>
> On 19.06.17 22:22, Rasmus Schultz wrote:
>
>> If I have
Well, the Ruby/Rust syntax would serve us well here too:
$things->forEach(|$v| {
foo($v);
bar($v);
});
On 19 Jun, 2017, at 09:43 PM, Rasmus Schultz wrote:
I actually like this syntax, but what would it look like for multi-statement
closures?
A nested set of curly braces around the bo
Hello Rasmus,
On 19.06.17 22:22, Rasmus Schultz wrote:
If I have to factor back and forth between new and old syntax every time a
closure changes from one to multiple or back to one statement, then,
frankly, what's the point?
I think I would just keep using the old syntax, then - for consistenc
So what's on the table is a syntax-improved but feature-crippled variant of
closures, not an all-round replacement?
If I have to factor back and forth between new and old syntax every time a
closure changes from one to multiple or back to one statement, then,
frankly, what's the point?
I think I
On 06/19/2017 03:45 PM, Rasmus Schultz wrote:
Or maybe it'll look okay if you format the code?
$things->forEach({$v => {
foo($v);
bar($v);
}});
Still looks kinda crazy with the closing "}})" though...
Multi-line lambdas should use the existing syntax without chan
Or maybe it'll look okay if you format the code?
$things->forEach({$v => {
foo($v);
bar($v);
}});
Still looks kinda crazy with the closing "}})" though...
On Mon, Jun 19, 2017 at 9:43 PM, Rasmus Schultz wrote:
> I actually like this syntax, but what would it look like
I actually like this syntax, but what would it look like for
multi-statement closures?
A nested set of curly braces around the body would look pretty messy.
$things->forEach({$v => { foo($v); bar($v); }});
On Mon, Jun 19, 2017 at 4:43 PM, Levi Morrison wrote:
> On Sun, Jun 18, 2017 at 1:4
On Sun, Jun 18, 2017 at 1:44 PM, Ilija Tovilo wrote:
> 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
On 18 June 2017 at 19:48, Rasmus Schultz wrote:
>
> I was referring to the visual ambiguity - the fn($x) part of the syntax is
> indistinguishable from a function-call.
Only to the same extent that if($x) {} is indistinguishable from a
function call.
Most people don't have a problem with this.
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 an
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 wrote:
> > I don't agree that the fn keyword solves the ambiguity pr
> 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 wrote:
>
> I don't agree that the fn keyword solv
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 namesp
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
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 mak
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
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
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->m
2017-06-10 11:09 GMT+02:00 Stephen Reay :
>
> > On 10 Jun 2017, at 15:19, Björn Larsson
> wrote:
> >
> > Den 2017-06-09 kl. 22:00, skrev Niklas Keller:
> >> 2017-06-09 15:44 GMT+02:00 Sara Golemon :
> >>
> >>> On Fri, Jun 9, 2017 at 7:23 AM, Björn Larsson <
> bjorn.x.lars...@telia.com>
> >>> wrot
> On 10 Jun 2017, at 15:19, Björn Larsson wrote:
>
> Den 2017-06-09 kl. 22:00, skrev Niklas Keller:
>> 2017-06-09 15:44 GMT+02:00 Sara Golemon :
>>
>>> On Fri, Jun 9, 2017 at 7:23 AM, Björn Larsson
>>> wrote:
If I take the liberty in using the example above on our option list:
1. $so
Den 2017-06-09 kl. 22:00, skrev Niklas Keller:
2017-06-09 15:44 GMT+02:00 Sara Golemon :
On Fri, Jun 9, 2017 at 7:23 AM, Björn Larsson
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(f
Den 2017-06-09 kl. 15:44, skrev Sara Golemon:
On Fri, Jun 9, 2017 at 7:23 AM, Björn Larsson 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) =
On Fri, Jun 9, 2017 at 4:43 PM, Rowan Collins wrote:
> On 9 June 2017 21:00:48 BST, Niklas Keller wrote:
>>2017-06-09 15:44 GMT+02:00 Sara Golemon :
>>
>>> On Fri, Jun 9, 2017 at 7:23 AM, Björn Larsson
>>
>>> wrote:
>>> > If I take the liberty in using the example above on our option
>>list:
>>>
On 9 June 2017 21:00:48 BST, Niklas Keller wrote:
>2017-06-09 15:44 GMT+02:00 Sara Golemon :
>
>> On Fri, Jun 9, 2017 at 7:23 AM, Björn Larsson
>
>> 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);
2017-06-09 15:44 GMT+02:00 Sara Golemon :
> On Fri, Jun 9, 2017 at 7:23 AM, Björn Larsson
> 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(func
On Fri, Jun 9, 2017 at 7:23 AM, Björn Larsson 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 *
Den 2017-06-09 kl. 02:13, skrev Sara Golemon:
On Thu, Jun 8, 2017 at 4:56 PM, Björn Larsson wrote:
You have a good point here! I think one then should evaluate
both the implementation, which apparently is not so great and
how the feature itself has been received.
I mean is it heavily used and
On Thu, Jun 8, 2017 at 4:56 PM, Björn Larsson wrote:
> You have a good point here! I think one then should evaluate
> both the implementation, which apparently is not so great and
> how the feature itself has been received.
>
> I mean is it heavily used and what is the user feedback? E.g. are
> us
Den 2017-06-08 kl. 19:21, skrev Fleshgrinder:
On 6/8/2017 6:28 PM, Rasmus Schultz wrote:
it could be a single symbol instead of two
even if this can be done without parser ambiguity, it suffers from visual
ambiguity with the assignment operator.
consider what this would look like if the expre
Den 2017-06-08 kl. 15:34, skrev Rowan Collins:
On 08/06/2017 13:33, Björn Larsson wrote:
One reason
(not the only one) for me to advocate ==> syntax is that it's the
same syntax as HACK
I'm not a fan of this logic. Using Hack as a kind of
prototyping-ground for PHP features is fine, but sinc
On 6/8/2017 6:28 PM, Rasmus Schultz wrote:
>> it could be a single symbol instead of two
>
> even if this can be done without parser ambiguity, it suffers from visual
> ambiguity with the assignment operator.
>
> consider what this would look like if the expression itself uses the
> assignment op
> it could be a single symbol instead of two
even if this can be done without parser ambiguity, it suffers from visual
ambiguity with the assignment operator.
consider what this would look like if the expression itself uses the
assignment operator...
f($x) = $y = $y + $x;
versus something l
On Thu, Jun 8, 2017 at 9:34 AM, Rowan Collins wrote:
> On 08/06/2017 13:33, Björn Larsson wrote:
>>
>> One reason
>> (not the only one) for me to advocate ==> syntax is that it's the
>> same syntax as HACK
>
>
> I'm not a fan of this logic. Using Hack as a kind of prototyping-ground for
> PHP feat
On 6/7/2017 9:45 PM, Rasmus Schultz wrote:
>> the `fn($a, $b) => $a + $b ** $c` syntax suddenly becomes an acceptable
> compromise.
>
> I have to second that.
>
> I might even propose to shorten it from "fn" to just "f" - the resulting
> syntax then resembles a mathematical predicate :-)
>
I re
On 08/06/2017 13:33, Björn Larsson wrote:
One reason
(not the only one) for me to advocate ==> syntax is that it's the
same syntax as HACK
I'm not a fan of this logic. Using Hack as a kind of prototyping-ground
for PHP features is fine, but since they don't have the same
decision-making proce
Den 2017-06-07 kl. 17:20, skrev Stephen Reay:
On 7 Jun 2017, at 20:37, Björn Larsson wrote:
Well, one reason to use fn or even lambda was to signal that this is
different then a regular function.
When it comes to number of keystrokes I guess that some inspiration
has been taken from other lang
> the `fn($a, $b) => $a + $b ** $c` syntax suddenly becomes an acceptable
compromise.
I have to second that.
I might even propose to shorten it from "fn" to just "f" - the resulting
syntax then resembles a mathematical predicate :-)
On Wed, Jun 7, 2017 at 5:20 PM, Stephen Reay
wrote:
>
> > On
> On 7 Jun 2017, at 20:37, Björn Larsson wrote:
>
> Well, one reason to use fn or even lambda was to signal that this is
> different then a regular function.
>
> When it comes to number of keystrokes I guess that some inspiration
> has been taken from other languages supporting arrow functions,
Den 2017-06-06 kl. 06:38, skrev Stephen Reay:
On 6 Jun 2017, at 03:18, Björn Larsson wrote:
Den 2017-06-05 kl. 21:23, skrev Ryan Pallas:
On Mon, Jun 5, 2017 at 1:09 PM, Fleshgrinder wrote:
On 6/5/2017 9:03 PM, Ryan Pallas wrote:
However, ($obj) -> $var is valid variable property syntax.
On 6/6/2017 6:38 AM, Stephen Reay wrote:
> As someone who sees limited appeal in short closures (Ok, they may
> make for slightly simpler constructs that are slightly too complex
> for a regular “collect” type collection method), I see a *lot* of
> people spending a *lot* of time to save typing 8 c
>
> On 6 Jun 2017, at 03:18, Björn Larsson wrote:
>
> Den 2017-06-05 kl. 21:23, skrev Ryan Pallas:
>
>> On Mon, Jun 5, 2017 at 1:09 PM, Fleshgrinder wrote:
>>
>>> On 6/5/2017 9:03 PM, Ryan Pallas wrote:
However, ($obj) -> $var is valid variable property syntax.
>>> Gosh, we really
Den 2017-06-05 kl. 21:23, skrev Ryan Pallas:
On Mon, Jun 5, 2017 at 1:09 PM, Fleshgrinder wrote:
On 6/5/2017 9:03 PM, Ryan Pallas wrote:
However, ($obj) -> $var is valid variable property syntax.
Gosh, we really have support for everything. :D That one is even very
important for stuff like
On 05/06/2017 20:09, Fleshgrinder wrote:
How about ~> which I at least cannot think of any place it is used at
all. ~ in binary negation and the only place we use it (I checked the
language parser this time to make sure).
We've come full circle: that was actually the syntax proposed in Bob
Wei
On Mon, Jun 5, 2017 at 1:09 PM, Fleshgrinder wrote:
> On 6/5/2017 9:03 PM, Ryan Pallas wrote:
> > However, ($obj) -> $var is valid variable property syntax.
> >
>
> Gosh, we really have support for everything. :D That one is even very
> important for stuff like `(new A)->f()`.
>
> How about ~> wh
On 6/5/2017 9:03 PM, Ryan Pallas wrote:
> However, ($obj) -> $var is valid variable property syntax.
>
Gosh, we really have support for everything. :D That one is even very
important for stuff like `(new A)->f()`.
How about ~> which I at least cannot think of any place it is used at
all. ~ in bi
On Jun 5, 2017 12:53 PM, "Fleshgrinder" wrote:
On 6/5/2017 8:36 PM, Rasmus Schultz wrote:
> Ugh, you're right, that's totally unreadable... the => is far too
ambiguous
> with array syntax, I agree.
>
> How about just a thin arrow?
>
> (params) -> expr
>
> If the parens around params were requ
On 6/5/2017 8:36 PM, Rasmus Schultz wrote:
> Ugh, you're right, that's totally unreadable... the => is far too ambiguous
> with array syntax, I agree.
>
> How about just a thin arrow?
>
> (params) -> expr
>
> If the parens around params were required, it's not ambiguous with the
> trailing -
Ugh, you're right, that's totally unreadable... the => is far too ambiguous
with array syntax, I agree.
How about just a thin arrow?
(params) -> expr
If the parens around params were required, it's not ambiguous with the
trailing -- operator, is it?
$foo->bar(($baz) -> $baz + 1);
Consi
Den 2017-06-05 kl. 19:55, skrev Rowan Collins:
On 5 June 2017 18:17:06 BST, Fleshgrinder wrote:
Could someone explain me again what the problem with the simple
fat-arrow and normal parenthesis is? Cannot find it anymore (too many
messages in too many thread I guess). I would guess that it has
On 6/5/2017 7:55 PM, Rowan Collins wrote:
> I think it's not just a case of implementation problems, it's actually
> ambiguous with current syntax:
>
> $foo = array( ($x) => 42 );
>
> Sure, those inner brackets are redundant, so it's not likely to break much
> actual code, but it's kind of weir
On 5 June 2017 18:17:06 BST, Fleshgrinder wrote:
>Could someone explain me again what the problem with the simple
>fat-arrow and normal parenthesis is? Cannot find it anymore (too many
>messages in too many thread I guess). I would guess that it has to do
>with the arbitrary look-ahead that is req
On 6/5/2017 6:17 PM, Larry Garfield wrote:
> 3 > 4 > 1.
>
> 2 is not even worth considering and I'd almost prefer not having arrow
> functions if their syntax is going to be that self-defeating.
>
> I also see no reason to include both by-value and by-reference binding
> Arrow functions are for
On 06/05/2017 09:19 AM, Rasmus Schultz wrote:
Of the proposed options, I'd prefer the double fat-arrow ==>
However, I remain of the opinion that all of those syntaxes are
work-arounds to ambiguity concerns for cases that likely don't actually
occur in real-world codebases.
I don't understand th
Of the proposed options, I'd prefer the double fat-arrow ==>
However, I remain of the opinion that all of those syntaxes are
work-arounds to ambiguity concerns for cases that likely don't actually
occur in real-world codebases.
I don't understand the motivation to design or optimize based on some
Den 2017-06-01 kl. 18:58, skrev Theodore Brown:
On Tuesday, May 30, 2017 at 12:58 PM, Levi Morrison wrote:
Based on the discussion there are a few different syntax choices
people liked. Overall it's a feature that people seem to want but
everyone seems to prefer a different syntax choice.
1.
On Tuesday, May 30, 2017 at 12:58 PM, Levi Morrison wrote:
> Based on the discussion there are a few different syntax choices
> people liked. Overall it's a feature that people seem to want but
> everyone seems to prefer a different syntax choice.
>
> 1. fn(params) => expr
> 2. function(params) =>
I think it’s worth noting that the people most excited about arrow functions
are probably the ones with a more functional approach.
Those kinds of side effects are usually avoided.
I also have nothing against capturing by reference. Given the last example:
fn($item) => $array[] = $item
All you
> I can’t think of a scenario where capturing by reference would be helpful in
> a single line closure.
function($item) use($array) {
return $array[] = $item;
}
It's actually one of the first closures I discovered in the wild when
looking for closures that would be candidates for
My preferences: 1, 3, 4, 5, (big void), 2.
I actually like 4 the most but I get that that might not be practical if it
leads to unexpected behaviour.
I can’t think of a scenario where capturing by reference would be helpful in a
single line closure. 5 just adds additional complexity with no add
On 31 May 2017 14:48:03 BST, Levi Morrison wrote:
>On Wed, May 31, 2017 at 7:36 AM, Rowan Collins
> wrote:
>> I was just pondering alternative approaches to stop the => token
>being ambiguous, and wondered if surrounding the whole expression with
>braces could work:
>>
>> { => $bound * 2 }
>> { $a
On Wed, May 31, 2017 at 7:36 AM, Rowan Collins wrote:
> On 30 May 2017 18:58:14 BST, Levi Morrison wrote:
>>Internals,
>>
>>The previous discussion thread has died down significantly and so I'd
>>like to start a new one to refocus. This message has some redundant
>>information by design so people
On 30 May 2017 18:58:14 BST, Levi Morrison wrote:
>Internals,
>
>The previous discussion thread has died down significantly and so I'd
>like to start a new one to refocus. This message has some redundant
>information by design so people don't have to reference the other
>thread so much.
>
>Based o
Den 2017-05-31 kl. 00:26, skrev Levi Morrison:
On Tue, May 30, 2017 at 3:37 PM, Björn Larsson
wrote:
Den 2017-05-30 kl. 21:40, skrev Derick Rethans:
On Tue, 30 May 2017, Levi Morrison wrote:
Internals,
The previous discussion thread has died down significantly and so I'd
like to start a n
On Tue, May 30, 2017 at 3:37 PM, Björn Larsson
wrote:
> Den 2017-05-30 kl. 21:40, skrev Derick Rethans:
>
>> On Tue, 30 May 2017, Levi Morrison wrote:
>>
>>> Internals,
>>>
>>> The previous discussion thread has died down significantly and so I'd
>>> like to start a new one to refocus. This messag
Den 2017-05-30 kl. 21:40, skrev Derick Rethans:
On Tue, 30 May 2017, Levi Morrison wrote:
Internals,
The previous discussion thread has died down significantly and so I'd
like to start a new one to refocus. This message has some redundant
information by design so people don't have to referenc
On Tue, 30 May 2017, Levi Morrison wrote:
> Internals,
>
> The previous discussion thread has died down significantly and so I'd
> like to start a new one to refocus. This message has some redundant
> information by design so people don't have to reference the other
> thread so much.
>
> Based o
Den 2017-05-30 kl. 20:24, skrev Levi Morrison:
On Tue, May 30, 2017 at 12:16 PM, Björn Larsson
wrote:
Den 2017-05-30 kl. 19:58, skrev Levi Morrison:
Internals,
The previous discussion thread has died down significantly and so I'd
like to start a new one to refocus. This message has some redun
>> You mentioned ability to explicitly specify binding as a possible extension.
>> However
>>
>> [$var1, $var2]()
>>
>> is not necessarily failing right now, it may be a valid array callable.
>>
>> Nikita
>
> As already mentioned we must maintain a leading `=` or `&`:
>
> [=, $var1, $var2]()
On Tue, May 30, 2017 at 12:36 PM, Nikita Popov wrote:
> On Tue, May 30, 2017 at 8:24 PM, Levi Morrison wrote:
>>
>> On Tue, May 30, 2017 at 12:16 PM, Björn Larsson
>> wrote:
>> > Den 2017-05-30 kl. 19:58, skrev Levi Morrison:
>> >>
>> >> Internals,
>> >>
>> >> The previous discussion thread has
On Tue, May 30, 2017 at 8:24 PM, Levi Morrison wrote:
> On Tue, May 30, 2017 at 12:16 PM, Björn Larsson
> wrote:
> > Den 2017-05-30 kl. 19:58, skrev Levi Morrison:
> >>
> >> Internals,
> >>
> >> The previous discussion thread has died down significantly and so I'd
> >> like to start a new one to
On Tue, May 30, 2017 at 12:16 PM, Björn Larsson
wrote:
> Den 2017-05-30 kl. 19:58, skrev Levi Morrison:
>>
>> Internals,
>>
>> The previous discussion thread has died down significantly and so I'd
>> like to start a new one to refocus. This message has some redundant
>> information by design so pe
Den 2017-05-30 kl. 19:58, skrev Levi Morrison:
Internals,
The previous discussion thread has died down significantly and so I'd
like to start a new one to refocus. This message has some redundant
information by design so people don't have to reference the other
thread so much.
Based on the disc
Internals,
The previous discussion thread has died down significantly and so I'd
like to start a new one to refocus. This message has some redundant
information by design so people don't have to reference the other
thread so much.
Based on the discussion there are a few different syntax choices
p
79 matches
Mail list logo
