Ecma does official HTML now.
/be
Tab Atkins Jr. wrote:
unofficial HTML version for everything.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Thu, Apr 18, 2013 at 4:07 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Note that Futures are entirely expressible in today's JS semantics.
(Not to say that it shouldn't be reviewed by the language gurus here,
just saying.)
JavaScript does not have an event loop (as I mentioned elsewhere)
On Thu, Apr 18, 2013 at 3:40 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Apr 18, 2013 at 4:07 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Note that Futures are entirely expressible in today's JS semantics.
(Not to say that it shouldn't be reviewed by the language gurus here,
just
Note that Futures are entirely expressible in today's JS semantics.
Even setting aside the event loop, this is arguable. Futures *as
implemented in libraries today* are expressible, sure. That's a tautology.
But there are cross-cutting issues at play, as Allen explained.
In the case of
On Thu, Apr 18, 2013 at 7:45 AM, Kevin Smith zenpars...@gmail.com wrote:
Note that Futures are entirely expressible in today's JS semantics.
Even setting aside the event loop, this is arguable. Futures *as
implemented in libraries today* are expressible, sure. That's a tautology.
But
GC is never required to be complete. We must allow the collector to not
collect some unreachable objects. This means that, without .done, there's
no guarantee that an unseen-rejection bug will ever get diagnosed.
Therefore we still need .done.
A perfect example of why the discussion should
From: Mark S. Miller [erig...@google.com]
GC is never required to be complete. We must allow the collector to not
collect some unreachable objects. This means that, without .done, there's no
guarantee that an unseen-rejection bug will ever get diagnosed. Therefore we
still need .done.
I
I still think the best solution to this is for the developer tools to
curate a list of unhandled rejections. Just like `window.onerror` and the
developer console work together to display unhandled exceptions, unhandled
rejections could be treated very similarly. They would appear in the
I'm not sure this is a perfect match, but:
The futures library and task scheduler I've been using in my applications
for around ~5 years does unhandled error detection and delayed error
handling.
For the former, the model is that the future has an internal callback that
is fired when a consumer
[es-discuss only fork]
Hi,
I'm forking this as I feel it surfaces an issue which I analyse as being
rooted in the ECMAScript organization. As I describe my opinion below,
please feel free to tell me I'm wrong in my analysis.
I'm sorry this is not a technical discussion, but I nonetheless
On Wed, Apr 17, 2013 at 10:28 AM, David Bruant bruan...@gmail.com wrote:
I'm also going to ask a pretty violent question, but: does it still need to
be spec'ed by ECMA? The only argument I've heard in favor of staying at ECMA
is that some people still find ISO standardization and Word/PDF
On Apr 17, 2013, at 10:28 AM, David Bruant wrote:
...
Although promises were planned for ES7, they weren't part of any formal spec.
As far as I know, no recent TC39 meetings even mentioned the concurrency
strawman [2].
i don't think the mention observation is totally correct. More
On Apr 17, 2013, at 10:48 AM, Tab Atkins Jr. wrote:
On Wed, Apr 17, 2013 at 10:28 AM, David Bruant bruan...@gmail.com wrote:
I'm also going to ask a pretty violent question, but: does it still need to
be spec'ed by ECMA? The only argument I've heard in favor of staying at ECMA
is that some
On Wed, Apr 17, 2013 at 12:06 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Note that there is an official HTML version
http://www.ecma-international.org/ecma-262/5.1/
Thanks!
This apparently has bad google-juice, and is not linked prominently in
the first couple results that I look at
Le 17/04/2013 21:03, Allen Wirfs-Brock a écrit :
On Apr 17, 2013, at 10:28 AM, David Bruant wrote:
...
Although promises were planned for ES7, they weren't part of any
formal spec. As far as I know, no recent TC39 meetings even mentioned
the concurrency strawman [2].
i don't think the
On Apr 17, 2013, at 2:25 PM, David Bruant wrote:
Le 17/04/2013 21:03, Allen Wirfs-Brock a écrit :
On Apr 17, 2013, at 10:28 AM, David Bruant wrote:
...
Although promises were planned for ES7, they weren't part of any formal
spec. As far as I know, no recent TC39 meetings even mentioned
On Wed, Apr 17, 2013 at 3:57 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
A a rule of thumb, if a library does something that can not be expressed in
the its base language there is a good chance it is extending the virtual
machine of the language and it should at least be reviewed from
17 matches
Mail list logo
