non-self referencial cyclical promises?

I was doing some recursive data structure work and ended up with a cyclical promise that did not use a direct self reference. It can be reduced down to: ```javascript var af, a = new Promise(f=>af=f); var bf, b = new Promise(f=>bf=f); af(b);bf(a); // the problem a.then(_=>_) // some env/libs

Re: Error stack strawman

On 02/19/2016 01:26 AM, Andreas Rossberg wrote: On 19 February 2016 at 03:13, Gary Guo > wrote: If we are not going to indicate tail call some way, debugging might be extremely difficult, and the stack result might be making no

Re: non-self referencial cyclical promises?

Bradley Meck wrote: I was doing some recursive data structure work and ended up with a cyclical promise that did not use a direct self reference. It can be reduced down to: ```javascript var af, a = new Promise(f=>af=f); var bf, b = new Promise(f=>bf=f); af(b);bf(a); // the problem

Re: non-self referencial cyclical promises?

With Mark’s direction, the v2 branch of Q handles "vicious cycles" through the WeakMap that maps promises to their underlying handler. Whenever a promise is resolved with another promise, it walks forward through the chain of promises that the promise handler "became" through resolution. The first

Re: Error stack strawman

On 2/24/16 5:35 PM, Boris Zbarsky wrote: Clearly this Just Works with a value property, across all browsers at that point, so we made it work with the accessor too. Oh, and we made it work the way [Replaceable] stuff on window works: the setter defines a value property on the object which

Re: Error stack strawman

Huh, weird. From the discussions that led to < https://github.com/claudepache/es-regexp-legacy-static-properties> being proposed and the discussion on that issue, for me to take a consistent position, I must sadly concede the following: We allowed a grossly leaky api (the RegExp statics, which

Re: Error stack strawman

On 2/24/16 4:30 PM, Mark S. Miller wrote: [1] For some reason the FF stack accessor has both getter and setter. I don't see any reason for a setter. We ran into code "in the wild" (more precisely, within our own test suite infrastructure, but we have no reason to believe this would not

Re: Will it be possible to retrieve a loaded module's exports synchronously?

I'm trying to do exactly what it sounds (I hope): given a path and the system loader registry, retrieve the module exports. This would allow an action to be taken only if the module hand already be loaded without forcing the module to be if it weren't. On Wed, Feb 24, 2016 at 3:08 PM, Caridy

Re: Will it be possible to retrieve a loaded module's exports synchronously?

var exports = System.loader.registery.get('path/file.js'); On Wed, Feb 24, 2016 at 3:53 PM, Caridy Patiño wrote: > There is no such thing as a `key` in 262 (module spec). The `key` is a > concept defined by the loader, and there it is not opaque. > I don't see where the value

Re: Will it be possible to retrieve a loaded module's exports synchronously?

inline (but again, we should move this conversation to the loader repo where you will get more people looking at your questions)... > On Feb 24, 2016, at 7:57 PM, John Lenz wrote: > > > var exports = System.loader.registery.get('path/file.js'); No, the registry

Re: Error stack strawman

On 02/24/2016 01:30 PM, Mark S. Miller wrote: [2] This solves only one of the cross-realm issue with stacks. It does nothing to address worries about cross-realm stacks. We do have code in FF that handles cross-realm stacks, or at least a close moral equivalent to them. The stacks are

Re: Will it be possible to retrieve a loaded module's exports synchronously?

There is no such thing as a `key` in 262 (module spec). The `key` is a concept defined by the loader, and there it is not opaque. > For my purpose the I would be interested in resolving the "name" so the > module exports can be retrieved. Can you explain more? Resolving from where? The context

Re: Will it be possible to retrieve a loaded module's exports synchronously?

On Wed, Feb 24, 2016 at 3:28 PM, Bradley Meck wrote: > In Node we can get the import path synchronously just from the parsed > module, as proposed API in > https://github.com/bmeck/node-eps/blob/es6-module/002-es6-modules.md > suggests. Can you clarify what you mean with

Re: Error stack strawman

On 2/24/16 6:59 PM, Steve Fink wrote: (Or at least, that's my understanding of what is going on. I'm not sure if that stuff is used for Error.stack yet.) It is. See https://bugzilla.mozilla.org/show_bug.cgi?id=1038238 -Boris ___ es-discuss mailing

non-self referencial cyclical promises?

When I first read that part of the spec, my understanding was that the two promises would cancel each other out by waiting for each other, but without performing an infinite set of PromiseJobs. The resolving functions created in step 1 of 25.4.2.2 that are set as reactions for the other promise

Re: Will it be possible to retrieve a loaded module's exports synchronously?

On Wed, Feb 24, 2016 at 7:35 PM, Caridy Patiño wrote: > inline (but again, we should move this conversation to the loader repo > where you will get more people looking at your questions)... > > https://github.com/whatwg/loader/issues/130 > On Feb 24, 2016, at 7:57 PM, John

Re: Setting initialValue of Array.prototype.reduce with a default argument

Changing `Array.prototype` isn’t worth the effort. Write your own reduce function that does exactly what you want: ```js function foldr (list, func, acc) { for (let i = list.length; --i >= 0;) acc = func(acc, list[i], i) return acc } ``` This will default the initial value to `undefined`

Will it be possible to retrieve a loaded module's exports synchronously?

Background: I'm trying to plan a migration to ES6 modules. For interop with the existing systems in the short-medium term, I would like to be able to retrieve a loaded modules exports synchronously (basically a "get or fail"). It looks like retrieving the exports synchronously is possible using

Setting initialValue of Array.prototype.reduce with a default argument

Not sure if this has been proposed, discussed, and soundly rejected before, but I wasn't able to find any mention of it in the archives. Let's say I'm using Array.prototype.reduce with an initialValue to convert an array into an object, like this: ```javascript [0,1,2,3,4].reduce((result, val)

Re: Will it be possible to retrieve a loaded module's exports synchronously?

I’m not sure what are you trying to do, but from within the module itself, you will have access to some metadata about the module, we have been chatting about `import()` and `import.` as the imperative forms to import relative modules, accessing module’s metadata, and potentially a reference to

Re: non-self referencial cyclical promises?

On Wed, Feb 24, 2016 at 11:54 AM, Bergi wrote: > Bradley Meck wrote: > >> I was doing some recursive data structure work and ended up with a >> cyclical >> promise that did not use a direct self reference. It can be reduced down >> to: >> >> ```javascript >> var af, a = new

Re: Error stack strawman

On Wed, Feb 24, 2016 at 11:40 AM, Steve Fink wrote: > On 02/19/2016 01:26 AM, Andreas Rossberg wrote: > > On 19 February 2016 at 03:13, Gary Guo wrote: > > If we are not going to indicate tail call some way, debugging might be >> extremely difficult, and

Re: Will it be possible to retrieve a loaded module's exports synchronously?

In Node we can get the import path synchronously just from the parsed module, as proposed API in https://github.com/bmeck/node-eps/blob/es6-module/002-es6-modules.md suggests. Can you clarify what you mean with > The "key" appears to only be resolvable asynchronously Which key? the path resolved

Re: Setting initialValue of Array.prototype.reduce with a default argument

That would prevent you from using an initial value that isn’t `undefined` while also coping with a reducer that might choose to return `undefined` — it would always be converted to the initial value, when you might actually want the `undefined` to propagate. But even without that little

Re: non-self referencial cyclical promises?

I agree that the standard shoudl require a deterministic error, and I thought it did. In https://tc39.github.io/ecma262/#sec-promise-resolve-functions: 6. If SameValue(resolution, promise) is true, then > a.Let selfResolutionError be a newly created TypeError object. > b.Return

Re: Error stack strawman

On Wed, Feb 24, 2016 at 2:37 PM, Boris Zbarsky wrote: > On 2/24/16 5:35 PM, Boris Zbarsky wrote: > >> Clearly this Just >> Works with a value property, across all browsers at that point, so we >> made it work with the accessor too. >> > > Oh, and we made it work the way