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
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
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
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
> 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
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
> 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
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
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
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
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
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
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:
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
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
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
> 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
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
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
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
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)
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,
> 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
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 *
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
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
>>
>>>
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:
>> >
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.
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.
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
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
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
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
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
> 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
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
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
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
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
> 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
> 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
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,
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
>
> 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
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
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
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
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
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
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);
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
>> 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:
>> >>
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
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
>>
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
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
79 matches
Mail list logo