RE: Formalize error.stack?

[John Lenz]

Column numbers are essential.
On Nov 12, 2013 12:28 PM, "Domenic Denicola" 
wrote:

>  I think V8's is preferred. IE10 adopted it, and there's a lot of
> stack-parsing going on in Node.js land. If SpiderMonkey and JSC would come
> around to that, it would be lovely.
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Weak callbacks?

[Tom Van Cutsem]

2013/11/13 Mark S. Miller 

> * Weak consistency (I know, people hear "CAP" and give up too much) won,
> which surprised some.
>
> Because Promises are asynchronous, even locally, the state of the world
> when a promise-based request is made differs from the one in which the
> request is received. Since partition induces rejection of all promises
> across that partition, connection recovery takes distinct paths through the
> code where one copes, in an application dependent manner, with having been
> out of communication.
>
> Further support for weak consistency should come at a higher level, e.g.,
> via the Unum model <
> https://www.cypherpunks.to/erights/talks/uni-tea/uni-tea.ppt>. Promises
> are a good substrate on which to build Una.
>

One of the most compelling approaches I've seen to date to enable eventual
consistency at a higher level is the recent work out of Microsoft Research
on cloud (data)types.
See . Tim
Coppieters, a student of mine, recently implemented the model as a pure JS
library, enabling easy replication of state among client and server
(node.js). His CloudTypes.js library is available at <
https://github.com/ticup/CloudTypes>. I'm pretty excited about the
elegance/simplicity of the model. The library is well-documented. Worth a
look for those into distributed systems.

Cheers,
Tom
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Weak callbacks?

[Tom Van Cutsem]

2013/11/11 Mark S. Miller 

> Much of the early Actors research
> DEC SRC Network Objects
> RMI
> Original-E before I arrived at Electric Communities
> Midori
> Orleans
> AmbientTalk
> Cap'n Proto
>

While I'm honored to see AmbientTalk listed among these systems, I should
note that, pertinent to this discussion, AmbientTalk made exclusive use of
leasing to manage distributed resources. There was no other form of DGC. It
was partly inspired by the leasing policies in .NET Remoting (.NET's
counterpart of Java RMI).

Cheers,
Tom
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Modules vs Scripts

[John Barton]

Could someone help me understand why two goals for parsing JS is a good
thing?


On Mon, Nov 11, 2013 at 3:30 PM, John Barton  wrote:

> Just a user-experience report with traceur: the following code fails to
> compile in the repl.html and command line compiler:
> -
> import {WrapNewObjectTransformer} from './WrapNewObjectTransformer';
>
> export function transcode(src, url) {
> var file = new SourceFile(url, src);
> var reporter = new ErrorReporter();
> var tree = new Parser(reporter, file).parseProgram(true);
> return (new WrapNewObjectTransformer()).transformAny(tree);
> }
> 
>
> It fails on 'unexpected token export'. This was unexpected by me ;-)
>
> However it does seem consistent with the grammar in
> http://wiki.ecmascript.org/doku.php?id=harmony:modules.  The |export|
> keyword is part of an ExportDeclaration which appears in a ModuleElement
> but not in a ScriptElement. The parser believes it is parsing a Script. So
> the only way to legally parse JS as a Module is as a side-effect of module
> loading?
>
> I suppose that a Script is intended to be the root of the dependency tree,
> so the error message is trying to tell me "You are compiling an interior
> node of the dependency tree silly". But both Script and Module are things
> that JS devs will want to compile. Concretely I will want to be able to
> copy the contents of a JS file and paste it into a repl window to analyze
> it without having it die on syntax errors because it is a module.
>
> hth,
> jjb
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Generator Arrow Functions

[Kevin Smith]

>
> Basically, as long as the outermost generator is
> run by an async runner, both lazy and async execution of all nested
> generators/iterators is possible.


Sure - it's the "async runner" part though (e.g. `spawn`), which is the use
case presented here.

async function F(p1, p2, ...pN) { /*...*/ }

Would (very) approximately de-sugar to something like:

function F(...args) {
return spawn(this, args, function* (p1, p1, ...pN) { /* ... */ });
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Generator Arrow Functions

[Brendan Eich]

I've added generator arrows to the TC39 meeting agenda for next week.

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Generator Arrow Functions

[Ѓорѓи Ќосев]

On 11/15/2013 06:07 PM, Kevin Smith wrote:
> Besides, with async functions, the use case established in this thread
> for generator arrows basically disappears.  It's probably better not
> to introduce convenience features that will be made obsolete by the
> next version of the language.

Can someone explain how would that use case disappear with "async
functions"?

If by "async functions" you mean something that would allow await [1] -
as far as I understand, this already works with generators:

function* getAllUserDataLazily() {
for (const userName of users) {
yield getUserData(userName);
}
}

function* outerGenerator() {
for (const dataPromise of getAllUserDataLazily()) {
console.log(yield dataPromise);
}
}

The inner `getAllUserDataLazily` generator yields promise values to the
`outerGenerator`, then pauses. The outer generator is run by the async
task runner and it yields the promise, then it also pauses. The task
runner's code now waits for the promise to resolve. Once the promise
resolves, it resumes the `outerGenerator`. Once the `outerGenerator`
resumes, it goes back to the beginning of the loop and resumes
`getAllUserDataLazily`. Basically, as long as the outermost generator is
run by an async runner, both lazy and async execution of all nested
generators/iterators is possible.

Another benefit is that this works with primitives other than promises.
Current libraries will love that, as not all are based on promises. By
the time ES7 is released, a large ecosystem of async generators will
already be in place. Infact, its already here, right now - and ES6 isn't
even finalized yet. This is a guess, but I'd say that at that point, a
new async functions feature will be seen as unnecessary and async
generators as "good enough". IMO, the cat is already out of the bag.

[1]: https://gist.github.com/domenic/6656283
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Generator Arrow Functions

[Claude Pache]

Le 15 nov. 2013 à 17:59, Rick Waldron  a écrit :

> 
> On Fri, Nov 15, 2013 at 11:34 AM, Axel Rauschmayer  wrote:
> 
> (...)
> 
> That would make the async programming code more compact, too (I’m assuming a 
> nullary paren-free arrow variant and I prefer the asterisk after the arrow):
> 
> To be clear, this preference is inconsistent with all other generator forms 
> where the asterisk is before the params, per Brandon's original examples.

The other point of view is that this preference is consistent with other 
generator forms where the asterisk is after the token that defines the general 
role of the construct as a procedure (either the `function` keyword, or the 
`=>` token). Personally, I tend to read `function*`as a unit meaning "generator 
function", and so would I for `=>*`.

—Claude

> 
> Rick
>  
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Generator Arrow Functions

[Axel Rauschmayer]

> Let me counter with:
> 
> function declaration, generator function declaration
> function expression, generator function expression
> concise method, concise generator method
> arrow function (, generator arrow function)

I don’t mind generator function declarations, but I personally will not use 
function declarations under ES6 (or at least try out const arrows and see how 
they feel). And I’ll do the same with generator function declarations, should 
we get generator arrow functions. If it works out then function declarations 
are a legacy feature (for me).

> That would make the async programming code more compact, too (I’m assuming a 
> nullary paren-free arrow variant and I prefer the asterisk after the arrow):
> 
> To be clear, this preference is inconsistent with all other generator forms 
> where the asterisk is before the params, per Brandon's original examples.

Ah, missed that. Thought it was *=>. I don’t mind either way, my (admittedly 
weak) mnemonic would be “asterisk after function-defining token”.

-- 
Dr. Axel Rauschmayer
a...@rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Generator Arrow Functions

[Kevin Smith]

> It would be great to have await, but in the meantime having generator
> functions would help male async methods tolerable. Await is ES7 at the
> earliest, generator arrow functions could be in ES6.
>

Adding new features to ES6 at this point in time?  I don't know...

Besides, with async functions, the use case established in this thread for
generator arrows basically disappears.  It's probably better not to
introduce convenience features that will be made obsolete by the next
version of the language.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Generator Arrow Functions

[Rick Waldron]

On Fri, Nov 15, 2013 at 11:34 AM, Axel Rauschmayer  wrote:

> It would be great to have await, but in the meantime having generator
> functions would help male async methods tolerable. Await is ES7 at the
> earliest, generator arrow functions could be in ES6.
>
>
> Couldn’t arrow generator functions replace generator function
> declarations? In other words: is the dynamic `this` in generator function
> declarations ever useful?
>

As useful as it is in non-generator function declarations and expressions.
I agree that a generator arrow function adds balance, but replacement of
generator function declarations contradicts a balance.


> Then we’d have a nice symmetry in ES6:
>
> – non-method function = const + arrow function.
> – method = concise method definition
>
> – non-method generator function = const + arrow generator function.
> – generator method = concise generator method definition
>

Let me counter with:

function declaration, generator function declaration
function expression, generator function expression
concise method, concise generator method
arrow function (, generator arrow function)




>
> That would make the async programming code more compact, too (I’m assuming
> a nullary paren-free arrow variant and I prefer the asterisk after the
> arrow):
>

To be clear, this preference is inconsistent with all other generator forms
where the asterisk is before the params, per Brandon's original examples.

Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Generator Arrow Functions

[Axel Rauschmayer]

> It would be great to have await, but in the meantime having generator 
> functions would help male async methods tolerable. Await is ES7 at the 
> earliest, generator arrow functions could be in ES6.


Couldn’t arrow generator functions replace generator function declarations? In 
other words: is the dynamic `this` in generator function declarations ever 
useful?

Then we’d have a nice symmetry in ES6:

– non-method function = const + arrow function.
– method = concise method definition

– non-method generator function = const + arrow generator function.
– generator method = concise generator method definition


That would make the async programming code more compact, too (I’m assuming a 
nullary paren-free arrow variant and I prefer the asterisk after the arrow):

```js
spawn(=>* {
var data = yield $.ajax(url);
$('#result').html(data);
var status = $('#status').html('Download complete.');
yield status.fadeIn().promise();
yield sleep(2000);
status.fadeOut();
});
```

Versus:

```js
spawn(function*() {
var data = yield $.ajax(url);
$('#result').html(data);
var status = $('#status').html('Download complete.');
yield status.fadeIn().promise();
yield sleep(2000);
status.fadeOut();
});
```

[Example taken from task.js website.]

-- 
Dr. Axel Rauschmayer
a...@rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Generator Arrow Functions

[Brandon Benvie]

On Nov 15, 2013, at 5:54 AM, Domenic Denicola  
wrote:

>> On 15 Nov 2013, at 08:47, "Kevin Smith"  wrote:
>> 
>> From the examples I've seen so far in this discussion, it's likely that what 
>> is wanted isn't generator arrows, as much as syntactic support for asyc 
>> functions.  Such a function, would, among other things, insure that all 
>> exceptions are converted to rejections, even exceptions occurring "in the 
>> head" (as can occur with argument destructuring and default parameter 
>> evaluation).
> 
> +1. Although, the outer-this-capturing nature of arrow functions would 
> probably be nice for some async functions too.

It would be great to have await, but in the meantime having generator functions 
would help male async methods tolerable. Await is ES7 at the earliest, 
generator arrow functions could be in ES6.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Generator Arrow Functions

[Domenic Denicola]

> On 15 Nov 2013, at 08:47, "Kevin Smith"  wrote:
> 
> From the examples I've seen so far in this discussion, it's likely that what 
> is wanted isn't generator arrows, as much as syntactic support for asyc 
> functions.  Such a function, would, among other things, insure that all 
> exceptions are converted to rejections, even exceptions occurring "in the 
> head" (as can occur with argument destructuring and default parameter 
> evaluation).

+1. Although, the outer-this-capturing nature of arrow functions would probably 
be nice for some async functions too.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Generator Arrow Functions

[Kevin Smith]

>From the examples I've seen so far in this discussion, it's likely that
what is wanted isn't generator arrows, as much as syntactic support for
asyc functions.  Such a function, would, among other things, insure that
all exceptions are converted to rejections, even exceptions occurring "in
the head" (as can occur with argument destructuring and default parameter
evaluation).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Generator Arrow Functions

[Ѓорѓи Ќосев]

On Thu 14 Nov 2013 11:16:22 PM CET, Brendan Eich wrote:
> Claus Reinke wrote:
>> What I don't understand is why generator expressions are not used
>> as the only way to create generators, leaving 'function' alone.
>
> We have been over this before: to support flows that for-of loops
> cannot expression, specifically coroutine libraries such as
> http://taskjs.org/.

The suggested topics seem to be ignoring that use case (using the result
of the yield expression) and only considering the iterator case. The
suggestion:

() => (for (y of gen) y)

isn't going to work for generators that need the values of the yield
expression (like in task.js), right?

spawn(() *=> yield (yield
this.user.getPendingFriendship(friendId)).setAccepted(true));

 From what I've seen, async generators are so popular (at least in
node-land) that people are building entire frameworks[1] and library
ecosystems[2] based on them even though they're only available behind a
flag, in an unstable version of node. Even more, a dedicated transpiler
was written[3] to support transpiling *just* generators, with the async
use case in mind.

Right now from where I stand, its almost as if the other use case of
generators (as iterators) is completely unimportant.

So I really don't see how there isn't a strong enough case for generator
arrow functions.

[1]: https://github.com/koajs/
[2]: https://github.com/visionmedia/co/wiki
[3]: http://facebook.github.io/regenerator/


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss