1. 5
  1. 1

    There’s a reason this sort of thing isn’t mainstream (anymore). “Async transparent” is a synonym for “free-threaded”. If you’re going to have mutable state you need some indicators of where discontinuities in state can happen (i.e., modified by non local code) to make reasoning about your code possible. The other way you can go is the Erlang design where suspending the local stack for IO doesn’t affect reasoning because there’s no local mutable state.

    1. 1

      yes, I don’t think async-transparency is a good fit for general purpose programming, but it is nice for front end scripting, and given the already-single-threaded nature of JavaScript, it works pretty well and opens up some nice patterns with respect to event-driven programming that are painful in JavaScript.

      a cool example is what we call “The Akşimşek Gambit”, a bit of code that Deniz Akşimşek wrote to make a div draggable:


      you can see it in action if you go to the (pretty spartan) demo page and select “Drag”:


      the crux of the algorithm is this:

                repeat until event pointerup from document
                  wait for pointermove(pageX, pageY) or
                           pointerup(pageX, pageY) from document
                  add { left: ${pageX - xoff}px; top: ${pageY - yoff}px; }

      where you loop until a pointer up from the document occurs, and then wait in the loop for either a move or pointer up.

      Insane, but it works, and it’s pretty darned cool.

      Which, come to think of it, is a pretty reasonable description of hyperscript…

      1. 2

        My point is that once you add “async transparency” (aka “green threads” or “coroutines”) it’s no longer “single threaded”.