Concurrency support?

[Lars T Hansen]

Nicolas Cannasse writes:
 > > It's not obvious that this has huge implications for the standard
 > > libraries in ECMAScript as they stand, but this type of problem will
 > > tend to make libraries more brittle in general.
 > > 
 > > The point I want to make is that we probably do not want to provide
 > > full continuations as an abstraction on which to build threads,
 > > coroutines, generators, exceptions, and so on, but instead to provide
 > > these other more controllable forms directly instead.
 > 
 > I agree that call/cc is not for the average user, and should be used
 > with the appropriate care. However, while it's important to provide the
 > different call/cc traditional usages (which you listed), it's also
 > important to provide the low-level call/cc access for users that want to
 > use it.
 >
 > There's been a lot of creativity in the past years about the way of
 > using continuations. I think we can except new paradigms in the future
 > as well. As a compiler writer, I prefer to be able to directly use
 > call/cc in the generated code and libraries instead of rewrapping and
 > sometimes abusing the standard ES4 library.

I don't think that being a compiler target is among the core use cases
for ECMAScript 4.  (Nor do I think it should be.)  I also don't think
that a pragmatic programming language like ECMAScript should follow
Scheme, say, in providing a minimalist and powerful core on which a
great variation of abstractions can be written by the initiated. 
Instead I think ECMAScript needs to be a rich language with features
that are immediately useful to its core audiences, and which play well
with each other in the sense that they have unsurprising consequences
when composed.

--lars