Concurrency support?

[Neil Mix]

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.

   -Neil