Concurrency support?

Neil Mix nmix at
Mon Jun 26 17:16:23 PDT 2006

On Jun 26, 2006, at 4:12 PM, Brendan Eich wrote:

> If this were 1995, *and* we had a sound library mechanism with the  
> right identity and security guarantees, I would agree.  But at this  
> point I agree with Lars: "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."

I'd like to think of myself as a member of the "core audience" (I  
have no formal PL theory background, I've been hacking web apps my  
entire career, I've never designed a language, and Wikipedia is the  
only reason I'm able to keep up -- albeit minimally -- with this  
discussion). I have to say, I believe this feature *is* immediately  
useful, and (perhaps this is my naivety talking) I believe it can  
avoid surprising consequences if done correctly.

Does the distinction between canonical continuations and "delimited  
continuations" matter at all?  If we drop canonical continuation  
support (which is a good idea IMO) and focus instead on delimited  
continuations, and furthermore concede that native calls are not  
allowed in the delimited portion of the stack (which I think is  
reasonable -- I'm not really sure how they'd show up there anyway),  
isn't this reasonably doable?  Granted, the tiny tree-walking parser  
can't rely on host recursion.  And granted, figuring out the right  
syntax for including the delimited stack as a parameter to the higher- 
up stack frames is a bit treacherous (especially since this is  
relatively new territory).

OTOH, I think the nature of JavaScript with it's callback-based APIs  
makes it ripe for this kind of enhancement.  Keep the simplicity of  
onReadyStateChange, setTimeout, addEventHandler et al., and yet  
provide a concurrency mechanism that is IMO a very natural (nay,  
expected) way to tie things together.  When I first started using  
JavaScript 5+ years ago, I was looking for a concurrency mechanism  
(even though I didn't know enough to call it "concurrency") within a  
month of starting my first project. I was astonished to find that  
none existed.  For the past 6 months or so I've been slowly teaching  
myself PL theory (in my spare time) so that I could take a stab at  
solving this problem by building a code generator (also in my spare  
time).  I didn't do this to be cool or l33t, I honestly did it so  
that the next time I build a JS app I'll be able to use a concurrency  
mechanism, so that my code is easier to follow and the asynchronicity  
doesn't drive me batty.  (too late, most would say ;)

When I researched for my code generator I found postings all over the  
web from people seeking concurrency in JS.  Many of them didn't have  
the vocabulary to describe it (just like me 5 years ago), but they're  
out there.  So I think I disagree with the assertion that this isn't  
useful to the core audience.  Whether it's doable in an unsurprising  
way I'm less certain of, but I'm still naively optimistic.


More information about the Es4-discuss mailing list