On Thu, Oct 1, 2015 at 1:40 PM, Levi Morrison wrote:
> > Or we can figure out some other such symbol. Worse casing no white space,
> > brain storming:
>
> Please, I already asked people to stop making suggestions for shorter
> syntax for `use()`. Again, if use() is a pain then auto-importing the
Hi,
Given the recent discussion about async/await keyword should one
also consider short closures supporting asynchronous functionality
in the future?
Stumbled upon it when reading about Async Lambdas in Hacklang
manual.
Regards //Björn Larsson
Den 2015-09-26 kl. 18:17, skrev Levi Morrison:
(
Den 2015-10-01 kl. 19:12, skrev Bishop Bettini:
On Thu, Oct 1, 2015 at 12:28 PM, Anthony Ferrara
wrote:
Nikita and all,
I don't think there was a dozen of different ideas, I could only find
those
about `lambda(arg-list; use-list; expression)` and variations of it with
different keywords an
Levi Morrison wrote on 01/10/2015 19:09:
You are capped to saving about 5-7 characters no matter what you do
with this functionality.
I see an upper limit to savings of 21 - using "|" to stand in for "some
single character delimiting the sections" gives:
|$x|$y|$x*$y| // 13 chars
vs
functi
On Thu, Oct 1, 2015 at 11:57 AM, Rowan Collins wrote:
> Levi Morrison wrote on 01/10/2015 18:40:
>>>
>>> Or we can figure out some other such symbol. Worse casing no white space,
>>> brain storming:
>>
>> Please, I already asked people to stop making suggestions for shorter
>> syntax for `use()`.
Levi Morrison wrote on 01/10/2015 18:38:
Chain works is because the functions passed to it accept iterables as
their only parameter and return either an another iterable or a
reducing function (in this example sum is the reducer). This is why
the functions are returning closures that accept only
Levi Morrison wrote on 01/10/2015 18:40:
Or we can figure out some other such symbol. Worse casing no white space,
brain storming:
Please, I already asked people to stop making suggestions for shorter
syntax for `use()`.
I tried to move the discussion to whether or not auto-capturing
variable
> Or we can figure out some other such symbol. Worse casing no white space,
> brain storming:
Please, I already asked people to stop making suggestions for shorter
syntax for `use()`. Again, if use() is a pain then auto-importing the
used variables is a good solution. If it's not a pain why are yo
On Thu, Oct 1, 2015 at 10:47 AM, Rowan Collins wrote:
> Levi Morrison wrote on 01/10/2015 16:52:
>>
>> This is
>> close:https://github.com/morrisonlevi/Algorithm/blob/master/src/reduce.php
>
>
> When would you store or pass around the intermediate callback (the result of
> reduce($initial)) withou
Nikita Nefedov wrote on 01/10/2015 15:58:
On Thu, 01 Oct 2015 15:33:51 +0300, Rowan Collins
wrote:
It is a tool for making them shorter, yes, but it is not the only
way, and it comes with a cost of changing established behaviour.
Again, look at C++'s lambda syntax - it is much shorter than PHP
On Thu, Oct 1, 2015 at 12:28 PM, Anthony Ferrara
wrote:
> Nikita and all,
>
> > I don't think there was a dozen of different ideas, I could only find
> those
> > about `lambda(arg-list; use-list; expression)` and variations of it with
> > different keywords and different return-type syntax.
> > I
Levi Morrison wrote on 01/10/2015 16:52:
This is
close:https://github.com/morrisonlevi/Algorithm/blob/master/src/reduce.php
When would you store or pass around the intermediate callback (the
result of reduce($initial)) without immediately invoking it with a
callback? If you just run "reduce(
Nikita and all,
On Thu, Oct 1, 2015 at 10:58 AM, Nikita Nefedov wrote:
> On Thu, 01 Oct 2015 15:33:51 +0300, Rowan Collins
> wrote:
>
>> That's not how Rasmus expressed it
>> [http://marc.info/?l=php-internals&m=144107616411299&w=2]:
>>
>> > I made a very deliberate decision In the very first i
>> And one thing that makes auto capture much better choice than explicit
>> capture (as it've been said a couple of times already) is partial
>> application:
>>
>> $mul = fn($x) => fn($y) => fn($z) => $x * $y * $z;
>>
>> Looks simpler than:
>>
>> $mul = fn($x) => fn($y; $x) => fn($z; $x, $
On Thu, Oct 1, 2015 at 8:58 AM, Nikita Nefedov wrote:
>
> I don't think there was a dozen of different ideas, I could only find
> those about `lambda(arg-list; use-list; expression)` and variations of it
> with different keywords and different return-type syntax.
> I do understand that this is qui
On Thu, 01 Oct 2015 15:33:51 +0300, Rowan Collins
wrote:
That's not how Rasmus expressed it
[http://marc.info/?l=php-internals&m=144107616411299&w=2]:
> I made a very deliberate decision In the very first implementation of
PHP to avoid scope side-effects like this. Inside a function eve
Nikita Nefedov wrote on 01/10/2015 12:07:
And yet we have super-globals. You can also access variables of one
script's global scope from another script's global scope without
importing or anything like that.
You are right, super-globals are an exception to the rule, because they
appear in all
On Thu, 01 Oct 2015 13:48:52 +0300, Rowan Collins
wrote:
Levi Morrison wrote on 01/10/2015 04:06:
I'm going to ask everyone to stop saying that auto-closing is bad
unless they also provide a demonstration of why it was bad.
Please see my e-mail from last night, or Rasmus's in the original
Levi Morrison wrote on 01/10/2015 04:06:
I'm going to ask everyone to stop saying that auto-closing is bad
unless they also provide a demonstration of why it was bad.
Please see my e-mail from last night, or Rasmus's in the original
thread. It is "bad" (or, controversial) because it is a funda
On Tue, Sep 29, 2015 at 11:55 PM, Levi Morrison wrote:
> Reading over the list I don't think people "are torn about" it. There
> are some detractors, sure, but there seem to be more detractors about
> symbol choice (~) and lack of type declarations.
Personally, I feel that without the auto impor
Den 2015-09-28 kl. 23:38, skrev Pavel Kouřil:
On Sat, Sep 26, 2015 at 6:17 PM, Levi Morrison wrote:
(Email in gist format:
https://gist.github.com/morrisonlevi/fa7984c04ff176b5a87c)
In EcmaScript 2015 (ES6) the expression `(x) => x * 2` means to create
an anonymous function with one parameter
On Wed, Sep 30, 2015 at 8:45 PM, Bishop Bettini wrote:
> On Sat, Sep 26, 2015 at 1:07 PM, Rowan Collins
> wrote:
>>
>> On 26/09/2015 17:17, Levi Morrison wrote:
>>>
>>> What concerns do you have about `fn($x) => $x * 2` or `function($x) =>
>>> $x * 2`? I will be writing a proper RFC later but I w
On Sat, Sep 26, 2015 at 1:07 PM, Rowan Collins
wrote:
> On 26/09/2015 17:17, Levi Morrison wrote:
>
>> What concerns do you have about `fn($x) => $x * 2` or `function($x) =>
>> $x * 2`? I will be writing a proper RFC later but I wanted to get
>> discussion going now.
>>
>
> If a keyword is requir
Marcio Almada wrote on 30/09/2015 15:49:
That's not to say that automatic capture is an absolute blocker, but I think
>"the internals community is divided on it" is a reasonable summary.
>
That's the part I couldn't comprehend in the discussion. Auto import
is basically the most interesting reas
Hi,
2015-09-30 8:10 GMT-03:00 Rowan Collins :
> Levi Morrison wrote on 29/09/2015 22:55:
>>>
>>> When you choose the function($x) ~> $x * 2 (or with ==> or =>
>>> >operator), you end up saving around 5 or 6 characters from the "long
>>> >declaration", ending up with "not-so-short closures" instead
> Am 26.9.2015 um 18:17 schrieb Levi Morrison :
>
> (Email in gist format:
> https://gist.github.com/morrisonlevi/fa7984c04ff176b5a87c)
>
> In EcmaScript 2015 (ES6) the expression `(x) => x * 2` means to create
> an anonymous function with one parameter `x` that will return `x * 2`.
> For exampl
Levi Morrison wrote on 29/09/2015 22:55:
When you choose the function($x) ~> $x * 2 (or with ==> or =>
>operator), you end up saving around 5 or 6 characters from the "long
>declaration", ending up with "not-so-short closures" instead. You save
>a little bit more if you have the implicit "use", b
On Tue, Sep 29, 2015 at 12:23 AM, Pavel Kouřil wrote:
> On Tue, Sep 29, 2015 at 12:52 AM, Levi Morrison wrote:
>>
>> I do not think it is feasible to make the parser do backtracking or
>> anything of that sort. How do others feel?
>>
>>> PS: the [fn($x) => $x * 2] seems ambigous, from reader's PO
On Tue, Sep 29, 2015 at 12:52 AM, Levi Morrison wrote:
>
> I do not think it is feasible to make the parser do backtracking or
> anything of that sort. How do others feel?
>
>> PS: the [fn($x) => $x * 2] seems ambigous, from reader's POV; key of
>> the item is result of fn($x) and value is $x * 2?
On Mon, Sep 28, 2015 at 3:38 PM, Pavel Kouřil wrote:
> On Sat, Sep 26, 2015 at 6:17 PM, Levi Morrison wrote:
>> (Email in gist format:
>> https://gist.github.com/morrisonlevi/fa7984c04ff176b5a87c)
>>
>> In EcmaScript 2015 (ES6) the expression `(x) => x * 2` means to create
>> an anonymous functio
On Sat, Sep 26, 2015 at 6:17 PM, Levi Morrison wrote:
> (Email in gist format:
> https://gist.github.com/morrisonlevi/fa7984c04ff176b5a87c)
>
> In EcmaScript 2015 (ES6) the expression `(x) => x * 2` means to create
> an anonymous function with one parameter `x` that will return `x * 2`.
> For exam
On 26/09/2015 19:37, Levi Morrison wrote:
Thank you for the feedback. I feel like the rest of what you proposed
was a bit too far outside of the box. For what it is worth no token
after the paren is necessary – you could do `fn($x) $x * 2` (or
`function($x) $x * 2`). I think this is a case where
On Sat, Sep 26, 2015 at 12:31 PM, Levi Morrison wrote:
> On Sat, Sep 26, 2015 at 11:07 AM, Rowan Collins
> wrote:
>> On 26/09/2015 17:17, Levi Morrison wrote:
>>>
>>> What concerns do you have about `fn($x) => $x * 2` or `function($x) =>
>>> $x * 2`? I will be writing a proper RFC later but I wa
On Sat, Sep 26, 2015 at 11:07 AM, Rowan Collins wrote:
> On 26/09/2015 17:17, Levi Morrison wrote:
>>
>> What concerns do you have about `fn($x) => $x * 2` or `function($x) =>
>> $x * 2`? I will be writing a proper RFC later but I wanted to get
>> discussion going now.
>
>
> If a keyword is requir
On 26/09/2015 17:17, Levi Morrison wrote:
What concerns do you have about `fn($x) => $x * 2` or `function($x) =>
$x * 2`? I will be writing a proper RFC later but I wanted to get
discussion going now.
If a keyword is required next to the parameters, having the => as a
separate token looks a bi
35 matches
Mail list logo
