For use cases that require named Functions (e.g. recursion), surely it's
not a such a big deal to either assign an Array Function to a variable
first, or use the good old trusty named Function expression or Function
statement.
var recurseExample = () => { recurseExample(); }
var recurseExample =
Ups, I answered only to Jacob but I think this is a real simple solution:
var factorial;
x.map(factorial = x => x < 1 ? 1 : x * factorial(x-1));
Or simply:
var factorial = x => x < 1 ? 1 : x * factorial(x-1);
x.map(factorial);
As you said, this is ocassionally needed. And for
And as Kevin said, it has been mentioned before (with event handlers and
timeouts as the initial driving force).
https://esdiscuss.org/topic/self-recursion-and-arrow-functions
On Tue, Aug 11, 2015, 21:57 Isiah Meadows wrote:
> Sent this too early... Corrected inline.
>
> On Tue, Aug 11, 2015, 2
Sent this too early... Corrected inline.
On Tue, Aug 11, 2015, 21:56 Isiah Meadows wrote:
The real reason people need named arrow functions, the biggest use case is
for event handlers.
```js
let p = new Promise((resolve, reject) =>
setTimeout((x => () => x(x))(handler => {
onNotNeeded(()
The real reason people need named arrow functions, the biggest use case is
for event handlers.
```js
let p = new Promise((resolve, reject) =>
setTimeout((x => () => x(x))(handler => {
onNotNeeded(() => clearTimeout(handler));
// `return` is to take advantage of TCO
return doSomethin
>
> My proposal is not a keyword, but an hidden variable included at functions
> (e.g. arguments).
> Does arrow functions have any limitations about that?
>
Yes. There are no special contextual keywords reserved within arrow
functions. We've discussed the possibility of a "meta property" for thi
>
> x.map(factorial(x) => do {
> if (x <= 1) {
> 1;
> } else {
> x * factorial(x - 1)
> }
> });
>
This has been discussed over the years but there has been very little
interest in making the grammar more complicated. After all, you can alway
Well, I found out arguments is actually a reserved word too haha
About that:
If they're not from the tiny set of remaining reserved words
(enum, anyone?), they can be users' identifiers, and have to be based
contextually on some enclosing syntax, like yield is.
That could be it, right? Since it
Yeah., that's what I meant.
My proposal is not a keyword, but an hidden variable included at functions
(e.g. arguments).
Does arrow functions have any limitations about that?
2015-08-11 21:35 GMT-03:00 Daniel Ehrenberg :
> I assume you mean more like this (without factorial):
>
> x.map((x) => d
I assume you mean more like this (without factorial):
x.map((x) => do {
if (x <= 1) {
1;
} else {
x * recur(x - 1)
}
});
One issue is that it's hard to add keywords to JavaScript at this
point. If they're not from the tiny set of remaining rese
What about a clojure like recur hidden variable binded to the bottom-level
function?
x.map(factorial(x) => do {
if (x <= 1) {
1;
} else {
x * recur(x - 1)
}
});
2015-08-11 21:26 GMT-03:00 Daniel Ehrenberg :
> In addition to being hard to parse
In addition to being hard to parse in general, I don't think this
would play very well with the async/await proposal
https://tc39.github.io/ecmascript-asyncawait/ , which wants to have
arrow functions like
async (x) => ...
Because we can't count on async as a keyword, your proposal would
create a
I don't think my earlier mail went through, so I'm posing it below for
the record:
SIMD types have bitwise operators, but SIMD.js exposes just fixed-size
vectors that are optimized to what hardware can optimize certain
operations for. A future extension (the "long SIMD API") may operate
on w
Daniel Ehrenberg wrote:
Uint8ClampedArray is more of a historical artifact than something you
should actually aim to use. Uint8Array is probably what you'd want to
get at as a basis for a user-level library.
Thanks for posting this, Daniel. Just to be super-clear (and I was
around when it was
Bits and bytes are fundamental to JavaScript too, which is why the
language has, for a long time, included operations like <<, >>, <<<,
&, |, ^ and ~ on Numbers, exposing the ability to manipulate 32-bit
integers. This is comparable to what C provides. Like C, JavaScript
has a relatively minimal st
Woah, an actual application of Y combinator hahaha
https://www.youtube.com/watch?v=FITJMJjASUs
On Tue, Aug 11, 2015 at 7:01 PM James M Snell wrote:
> On Tue, Aug 11, 2015 at 2:21 PM, Tab Atkins Jr.
> wrote:
> [snip]
> >
> > let Y = F => (x=>F(y=>(x(x))(y)))(x=>F(y=>(x(x))(y)));
> >
>
> Aah
On Tue, Aug 11, 2015 at 2:21 PM, Tab Atkins Jr. wrote:
[snip]
>
> let Y = F => (x=>F(y=>(x(x))(y)))(x=>F(y=>(x(x))(y)));
>
Aahh! my eyes! it burns!!!
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Tue, Aug 11, 2015 at 1:49 PM, Jacob Parker wrote:
> I did look, but couldn’t find anything on named arrow functions were not
> included. I do sometimes find cases where I want recursion inside a class
> function definition, and still need access to `this`. Was it just seen as
> syntax bloat,
I did look, but couldn’t find anything on named arrow functions were not
included. I do sometimes find cases where I want recursion inside a class
function definition, and still need access to `this`. Was it just seen as
syntax bloat, or were there any complications to implementing it?
Obviousl
SIMD types appear almost as limited in size as using numbers. Often I need to
manipulate thousands or millions of bits efficiently so fumbling around with
numbers is messy.
I've looked at several implementations on npm but none seemed very mature or
standard.
I guess it's philosophical as much
On Aug 11, 2015, at 10:26 AM, Michael Dyck wrote:
> On 15-08-11 11:47 AM, Allen Wirfs-Brock wrote:
>>
>> On Aug 10, 2015, at 6:03 PM, Michael Dyck wrote:
>>
>>> While converting the HTML spec into ecmarkup, I found roughly 100
>>> glitches (depending on what and how you count),
>>
>> Have you
On 15-08-11 11:47 AM, Allen Wirfs-Brock wrote:
On Aug 10, 2015, at 6:03 PM, Michael Dyck wrote:
While converting the HTML spec into ecmarkup, I found roughly 100
glitches (depending on what and how you count),
Have you checked them against http://ecma-international.org/ecma-262/6.0/
? It wou
Rick Waldron wrote:
(Slides are at https://github.com/tc39/tc39-notes/tree/master/es7/2015-07 )
# July 30 2015 Meeting Notes
Allen Wirfs-Brock (AWB), Sebastian Markbage (SM), Jafar Husain (JH),
Eric Farriauolo (EF), Caridy Patino (CP), Waldemar Horwat (WH), Istvan
Sebastian (IS), Mark Miller
On Aug 10, 2015, at 6:03 PM, Michael Dyck wrote:
> On 15-08-10 03:14 PM, Allen Wirfs-Brock wrote:
>>
>> There is also now a bugzilla component for ticketing rendering bugs in
>> the HTML version of the ES6 spec:
>> https://bugs.ecmascript.org/buglist.cgi?product=ECMA-262%20Edition%206&component=
Okay... Maybe not CoffeeScript (don't normally use it), but I know a few
notable derivatives have that (particularly Coco and LiveScript).
As for the idea itself, still a -1 from me. Unless we add an equivalent for
every binary operator, it's not much of an addition. It's just another
special case
25 matches
Mail list logo