On Sun, Apr 21, 2013 at 6:55 PM, David Herman dher...@mozilla.com wrote:
On Apr 20, 2013, at 9:21 PM, Mark S. Miller erig...@google.com wrote:
* Communicating Event Loop concurrency model,
- with the two-priority event loop already required by both
browser and server.
*
Indeed. Thanks for reviving this thread. Altogether, I'm pleasantly
surprised how well this old thread holds up in light of more recent events.
On Fri, May 2, 2014 at 2:57 AM, Dmitry Lomov dslo...@google.com wrote:
On Sun, Apr 21, 2013 at 6:55 PM, David Herman dher...@mozilla.com wrote:
My apologies, I didn't mean it as a rebuke ( although looking at what
I wrote I can understand the thought ).
I was a bit unsure about floating back up another email like this when
it seemed people maybe weren't interested in the topic. Obviously I
did an awful job at conveying that feeling.
On Sun, Apr 28, 2013 at 4:23 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Sun, Apr 28, 2013 at 3:16 PM, Brendan Eich bren...@mozilla.com wrote:
Brian Di Palma wrote:
Another mail that I expected to receive more attention that hasn't...
@Brian, This is the second time you've opened
Rick Waldron wrote:
Mark Miller and I had an offline discussion that clarified for me that
the example using a symbol as a property key would allow the value to
be discovered via ES6's Object.getOwnPropertyKeys() which returns the
result of the internal [[OwnPropertyKeys]] method. The mistake
Le 29/04/2013 18:09, Brendan Eich a écrit :
Users want class-private (and module-private?) syntax.
I'm not up-to-date on the module work, but last I looked at it, module
private is everything except what is explicitly exported, no? (which is
a good thing, I believe)
David
David Bruant wrote:
Le 29/04/2013 18:09, Brendan Eich a écrit :
Users want class-private (and module-private?) syntax.
I'm not up-to-date on the module work, but last I looked at it,
module private is everything except what is explicitly exported, no?
(which is a good thing, I believe)
Another mail that I expected to receive more attention that hasn't...
We're London based so we had attendants at JQueryUK and the announcement of
private class state in ES6 was a surprise, a pleasant one but still surprising.
Is it the case that the announcement was jumping the gun?
Needless to
Brian Di Palma wrote:
Another mail that I expected to receive more attention that hasn't...
For some reason my mail program doesn't thread your reply to my o.p.
Here it is in the archive, FWIW:
https://mail.mozilla.org/pipermail/es-discuss/2013-April/029969.html
We're London based so we
On Sun, Apr 28, 2013 at 3:16 PM, Brendan Eich bren...@mozilla.com wrote:
Brian Di Palma wrote:
Another mail that I expected to receive more attention that hasn't...
@Brian, This is the second time you've opened a thread reply with a rebuke
regarding (lack of) speedy of response. Just
We clearly don't quite have consensus, as your interaction at that
meeting helped highlight. I'd like to restore consensus, not break it.
What goes into a particular edition of ECMA-262 is less important than
making progress on draft emerging-consensus specs for private-in-class,
Le 21/04/2013 19:22, Brendan Eich a écrit :
At JQueryUK, I threw up a sketch in slides based on
http://wiki.ecmascript.org/doku.php?id=strawman:relationships:
|class SkinnedMesh extends THREE.Mesh{
private identityMatrix,
bones,
boneMatrices;
constructor(geometry,
On Sun, Apr 28, 2013 at 2:33 PM, David Bruant bruan...@gmail.com wrote:
Le 21/04/2013 19:22, Brendan Eich a écrit :
At JQueryUK, I threw up a sketch in slides based on
Le 29/04/2013 00:32, Mark S. Miller a écrit :
On Sun, Apr 28, 2013 at 2:33 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 21/04/2013 19:22, Brendan Eich a écrit :
At JQueryUK, I threw up a sketch in slides based on
David Bruant wrote:
ooohh Yes it does. I hadn't thought of WeakMaps for the
private syntax.
Sounds good then.
Another point Mark and Tom made that I found helpful:
The traditional GC-costly WeakMap implementation, which handles cases
where the map and its keys' lifetimes are not
On Tue, Apr 23, 2013 at 8:01 AM, Mark S. Miller erig...@google.com wrote:
Hi Kevin, you are correct that it isn't a co-routine, and that it
corresponds to a mechanical CPS rewrite of only the local function itself.
Fortunately, it is *exactly* the same CPS rewrite required to account for
the
Is there any chance at all of macros á la sweet.js will be on the agenda
for ES7 (or 8)?
I would very much like for that to happen to enable even more, and more
light-weight, experimentation with and cow-path building for the syntactic
language surface.
On Sun, Apr 21, 2013 at 5:21 AM, Mark S.
Also, see Peter Hallams part from NodeConf 2011 where he walks through how
await works: http://youtu.be/ntDZa7ekFEA?t=17m2s
On Wed, Apr 24, 2013 at 10:18 AM, Erik Arvidsson
erik.arvids...@gmail.comwrote:
On Tue, Apr 23, 2013 at 8:01 AM, Mark S. Miller erig...@google.comwrote:
Hi Kevin, you
On Sun, Apr 21, 2013 at 5:21 AM, Mark S. Miller erig...@google.com wrote:
Thoughts?
I was wondering when operator overloading is planned. It would be
great to be able to do things like new URL(http://example.org;) ==
new URL(http://example.org/;).
--
http://annevankesteren.nl/
On Wed, Apr 24, 2013 at 11:04 AM, Anne van Kesteren ann...@annevk.nlwrote:
On Sun, Apr 21, 2013 at 5:21 AM, Mark S. Miller erig...@google.com
wrote:
Thoughts?
I was wondering when operator overloading is planned. It would be
great to be able to do things like new URL(http://example.org;)
Le 24/04/2013 17:20, Dean Landolt a écrit :
On Wed, Apr 24, 2013 at 11:04 AM, Anne van Kesteren ann...@annevk.nl
mailto:ann...@annevk.nl wrote:
On Sun, Apr 21, 2013 at 5:21 AM, Mark S. Miller
erig...@google.com mailto:erig...@google.com wrote:
Thoughts?
I was wondering when
The Roadmap will be on the agenda for the upcoming TC39 May meeting. Many
of us want macros eventually, the ES6 module system gives us the stage
separation necessary for clean macros, and I don't recall any objections to
eventually including macros if they are clean enough. But macros are a big
Thanks, that makes a lot of sense to me.
On Wed, Apr 24, 2013 at 4:36 PM, Mark S. Miller erig...@google.com wrote:
The Roadmap will be on the agenda for the upcoming TC39 May meeting. Many
of us want macros eventually, the ES6 module system gives us the stage
separation necessary for clean
On Tue 23 Apr 2013 01:31, Tab Atkins Jr. jackalm...@gmail.com writes:
On Mon, Apr 22, 2013 at 2:45 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu
wrote:
What exactly would be the semantic difference between this and just using
'yield'?
The semantic difference is that 'yield' pauses your
Le 23/04/2013 01:31, Tab Atkins Jr. a écrit :
On Mon, Apr 22, 2013 at 2:45 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
What exactly would be the semantic difference between this and just using
'yield'?
The semantic difference is that 'yield' pauses your execution and
gives control to the
My information may be incomplete (I haven't used await since the beta of
the release that introduced it), but 'await' is part of the function's
return type/signature in C#; that is, a function that may await has a
different signature than a function that may not.
Calling a function that may await
On Tue, Apr 23, 2013 at 12:12 AM, Andy Wingo wi...@igalia.com wrote:
On Tue 23 Apr 2013 01:31, Tab Atkins Jr. jackalm...@gmail.com writes:
On Mon, Apr 22, 2013 at 2:45 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu
wrote:
What exactly would be the semantic difference between this and just
Hi David, see my response to Andy. await is just yield within a
Q.async(function*. Both async-functions/await are generators/yield are
shallow. Thus neither create the hazards of co-routines.
On Tue, Apr 23, 2013 at 1:26 AM, David Bruant bruan...@gmail.com wrote:
Le 23/04/2013 01:31, Tab
Hi Kevin, you are correct that it isn't a co-routine, and that it
corresponds to a mechanical CPS rewrite of only the local function itself.
Fortunately, it is *exactly* the same CPS rewrite required to account for
the semantics of generators/yield as a mechanical transform. This is in
fact how
On Tue, Apr 23, 2013 at 12:12 AM, Andy Wingo wi...@igalia.com wrote:
On Tue 23 Apr 2013 01:31, Tab Atkins Jr. jackalm...@gmail.com writes:
On Mon, Apr 22, 2013 at 2:45 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu
wrote:
What exactly would be the semantic difference between this and just using
On Tue, Apr 23, 2013 at 4:56 AM, Mark S. Miller erig...@google.com wrote:
On Tue, Apr 23, 2013 at 12:12 AM, Andy Wingo wi...@igalia.com wrote:
On Tue 23 Apr 2013 01:31, Tab Atkins Jr. jackalm...@gmail.com writes:
On Mon, Apr 22, 2013 at 2:45 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu
wrote:
On Sun, Apr 21, 2013 at 9:29 PM, Mark S. Miller erig...@google.com wrote:
Agreed that Object.freeze does not give you what you need.
RiverTrail already needs a kind of collection that is transitively
immutable by construction. They need this for safe data parallelism. But
the reason they are
Persistent immutable data structures would be a big usability improvement
in their own right. In a world where it's just as cheap and convenient to
use immutable structures as it is to depend on side-effects, code that does
this (including your own) would be a whole lot easier to reason about
From: Sam Tobin-Hochstadt [sa...@ccs.neu.edu]
I don't see what the point of `await` is in your gist. It looks like all of
the work is being done by `function^`, which looks to be sugar for creating a
function and passing it to a scheduler like `Q.async` or `taskjs.spawn`. We
could add
What exactly would be the semantic difference between this and just using
'yield'?
Sam
On Apr 22, 2013 5:40 PM, Domenic Denicola dome...@domenicdenicola.com
wrote:
From: Sam Tobin-Hochstadt [sa...@ccs.neu.edu]
I don't see what the point of `await` is in your gist. It looks like
all of the
From: sam...@gmail.com [sam...@gmail.com]
What exactly would be the semantic difference between this and just using
'yield'?
You mean, if you replaced my example by
```js
function*^ doubleSomeNumbers() {
const numbers = yield getNumbersToDouble();
for (var i = 0; i numbers.length; ++i)
On Apr 21, 2013, at 2:05 PM, David Bruant bruan...@gmail.com wrote:
Data ownership (like HTML5 Transferables or Rust unique pointers) is another
interesting track that covers different (also interesting) use cases in my
opinion.
Probably to be considered as part of the ES7/ES8 work on The
On Mon, Apr 22, 2013 at 2:45 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
What exactly would be the semantic difference between this and just using
'yield'?
The semantic difference is that 'yield' pauses your execution and
gives control to the calling code, while 'await' pauses your
* Sam Tobin-Hochstadt wrote:
What exactly would be the semantic difference between this and just using
'yield'?
If you consider it from the perspective of someone reading the code, you
might find, as an example, `try { ... yield ... }` rather weird (how can
yielding control fail?) while `try {
not sure I understand those examples, but the moment a developer starts
yelding everything, is the moment all non-blovking asynchronous advantages
are gone 'cause you are waiting instead of keep doing the rest, isn't it?
On Sat, Apr 20, 2013 at 9:56 PM, Domenic Denicola
On Sun, Apr 21, 2013 at 12:21 AM, Mark S. Miller erig...@google.com wrote:
I hesitate to put Module Loaders on the above list rather than leaving them
in ES6; but it would allow their semantics to rest on event loops and their
API to rest on promises. If we can get ES7 out quickly, this need
On Sun, Apr 21, 2013 at 12:56 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Finally, I know a lot of people, myself included, are excited about `await`
sugar. That is, the plan would be to use generators + promises in ES6 with
the awkwardness that entails; once we know what the
* Andrea Giammarchi wrote:
not sure I understand those examples, but the moment a developer starts
yelding everything, is the moment all non-blovking asynchronous advantages
are gone 'cause you are waiting instead of keep doing the rest, isn't it?
A simple example would be an application running
* Sam Tobin-Hochstadt wrote:
I don't see what the point of `await` is in your gist. It looks like
all of the work is being done by `function^`, which looks to be sugar
for creating a function and passing it to a scheduler like `Q.async`
or `taskjs.spawn`. We could add that sugar if we wanted,
On Sun, Apr 21, 2013 at 9:20 AM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
* Sam Tobin-Hochstadt wrote:
I don't see what the point of `await` is in your gist. It looks like
all of the work is being done by `function^`, which looks to be sugar
for creating a function and passing it to a scheduler
* Sam Tobin-Hochstadt wrote:
On Sun, Apr 21, 2013 at 9:20 AM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
* Sam Tobin-Hochstadt wrote:
I don't see what the point of `await` is in your gist. It looks like
all of the work is being done by `function^`, which looks to be sugar
for creating a function
On Apr 20, 2013, at 9:21 PM, Mark S. Miller erig...@google.com wrote:
* Communicating Event Loop concurrency model,
- with the two-priority event loop already required by both browser and
server.
* Object.observe
* Distribution compatible promises (at least Promises/A+)
*
Domenic Denicola wrote:
This looks lovely.
The only thing I'd want to add: we need integers! And generally better numeric
types. From speaking to developers on the ground, this is the biggest missing
language feature they see (that isn't already addressed in ES6). I know Brendan
has made
Trimming cc: list to just es-discuss.
Mark S. Miller wrote:
* Completing the class design
- at least high integrity and private state
If I'm not mistaken, we need class-private syntax for classes to have
ultimate double-blind consensus in *ES6*. See last meeting notes.
At JQueryUK,
Le 21/04/2013 19:09, Brendan Eich a écrit :
Domenic Denicola wrote:
Doing a quick poll of some IRC rooms, there's some call for
shared-memory multithreading. I know this was a concern of the asm.js
project, or more generally for the JS-as-a-compilation-target
mission. I don't think this is a
For some subset of use cases I imagine shared-memory multithreading being
limited to immutable objects could do the trick. Of course, I don't know if
real immutability is actually possible in ES as currently specified - if I
called Object.freeze or Object.seal on a JS object would it actually be
isn't typeof (console.log) function and not object? by object I meant
an Object object, not 'any arbitrary JS value'. I suppose the distinction
is really blurry, and you would still have to deal with problems like the
object's prototype chain containing callables...
On Sun, Apr 21, 2013 at 3:42
Then consider `Object.freeze(console)`.
Fundamentally, frozen objects are not appropriate for prohibiting shared state.
Sam
On Sun, Apr 21, 2013 at 6:44 PM, Kevin Gadd kevin.g...@gmail.com wrote:
isn't typeof (console.log) function and not object? by object I meant an
Object object, not 'any
Agreed that Object.freeze does not give you what you need.
RiverTrail already needs a kind of collection that is transitively
immutable by construction. They need this for safe data parallelism. But
the reason they are safe for parallel access within a vat/worker is the
same reason they would be
(Thanks to Rick Waldron and Brendan Eich for encouragement towards posting
this)
As we see on es-discuss, the pressure towards standardizing soon various
features currently absent from ES6 is increasing. Rather than stretch ES6,
I think we should work towards completing ES6 asap, and then proceed
This looks lovely.
The only thing I'd want to add: we need integers! And generally better numeric
types. From speaking to developers on the ground, this is the biggest missing
language feature they see (that isn't already addressed in ES6). I know Brendan
has made some moves in this direction
56 matches
Mail list logo
