

StratifiedJS: Javascript + structured concurrency - danh
http://onilabs.com/stratifiedjs

======
olegp
If you prefer vanilla JS and are only working with Node, you should check out
<https://github.com/laverdet/node-fibers>. I use it in my
<https://github.com/olegp/common-node> package to address the same issues as
those tackled by StratifiedJS.

------
skrebbel
I'm probably missing something, but isn't this race condition galore? As per
the front page example:

    
    
        var news;
        waitfor {
          news = http.get("http://news.bbc.co.uk");
        }
        or {
          hold(1000);
          news = http.get("http://news.cnn.com");
        }
        or {
          hold(1000*60);
          throw "sorry, no news. timeout";
        }
        show(news);
    

This starts the first 'or' clause the moment the http.get(BBC) suspends, which
it does quickly because http.get is async. Now, if the BBC get returns _just_
after my hold(1000) has completed but before http.get(CNN) had the time to
really launch the http request and suspend, i'll have done the CNN get for
nothing.

Of course in this case this only means a wasted request. But what in case of
side effects?

~~~
jerf
Ignoring WebWorkers, the underlying Javascript engine is single-threaded, so
the problem you describe can't exist. Once you start down a code path, it will
continue until it finishes and yields execution.

Further, "hold" is almost certainly a magical statement that actually compiles
into a pattern of calls to .setTimeout and various handlers, and has no
literal existence, so there probably isn't any point at which the hold is
"executed".

You can't actually turn a single-thread runtime into a threaded runtime at the
user level. You can apply a series of increasingly sophisticated hacks that
may make program like it's multithreaded, but you can't escape the fact you
have only one program counter. (This isn't a criticism of the library. It
looks quite useful. It just doesn't magically make browser Javascript truly
multithreaded.)

This approach is actually quite useful, and is part of what makes the event-
based programming style practical. For all the stuff that's going on, you do
always have the guarantee that any given event handler will fully execute, and
no other hunk of code will be able to observe the half-executed state of any
given handler. Without that property you'd basically just be doing
conventional multithreading with a really inconvenient code structure.

------
jashkenas
After the IcedCoffeeScript post the other day, I found Oni Labs' version --
which I don't remember seeing before -- Stratified CoffeeScript:

<https://github.com/onilabs/coffee-script>

------
beggi
Eliminating nested callbacks would be one hell of a feat.

~~~
lalc
It's not too _too_ hard to do the appropriate transformations--the literature
is vast and there are practical implementations today. The hard part is
producing readable, debuggable output.

I've whipped up a tiny project with the priorities inverted: readable output
at the expense of completeness: <https://github.com/lalcmellkmal/nestless>

It only does the minimum desugaring to prevent nesting in the common case, no
more.

