As far as I remember (maybe Arnar or Úlfar or another of the authors would have a different memory, though) we just wanted a “cool cookie” name. We knew about the -oon/-on distinction and liked the sound of -oon.
I view it as a mild plus that the confusion around the name has educated so many about confectionery taxonomies.
If it helps to think about the issue, we have a (free, online) book that manages this transition, so we've thought about this quite a bit and one co-author has been teaching a Pyret -> Python flow for several years. [https://dcic-world.org/2021-08-21/part_intro.html]
Various flavors of a course based on "An Incremental Approach to Compiler Construction" [1] have most or all materials free online, some with excellent notes. Taught at UCSD, Northeastern, Swarthmore College:
It's worth noting that Stopify itself isn't an editor or IDE as the title suggests.
Stopify is a JavaScript -> JavaScript compiler, implemented as a Babel transform, that enables pausing and restarting control operators for JavaScript programs.
A lot of the comments note the rich history of systems for debugging and execution control. Stopify's goal is to enable those kinds of systems, efficiently, while constrained by the browser's execution model.
WOW. I was not interested at all in this the way that the title implied but now that you describe what it actually does, this does indeed look useful.
The first line of the description should probably be scrapped. The interesting bit about this is not at all the fact there is an editor. Maybe it should be mentioned as a footnote but not as the lead-in.
Nice! Something like this is super-important for user experience.
This is a problem we've thought a lot about with Pyret, and have different concrete solutions. Rather than use heuristics that turn long-running computations into errors, we capture continuations and yield to the browser periodically. This allows long-running computations to eventually complete, while allowing the user to fully interact with buttons and the page while it's happening. This generalizes to nice abstractions for functional event loops and ways to manage asynchronous APIs for novices.
The Doppio JVM and the Whalesong compiler for Racket have similar underlying approaches.
It's quite a bit of effort to work around this inherent limitation of the browser's evaluation model for web-based IDEs!
First of all big fan of Pyret. And I (the author) did something similar in the past and I totally agree it's the way to go. What I did is exploded every JavaScript program on statements, wrapped function calls with thunks, and then converted the program and every function to a generator and inserted a yield statement between every other statement.
It worked well enough and was able to build a couple of demos on top of it (last time I checked chrome broke some of my demos so try them on other browsers). However, I think it's quite a hack and that the proper solution would be to build a JS VM. There are still issues to be worked out there like the problem that you can't instrument native code (say an event handler, or built-in functions) and that there are things that are inherently synchronous in the browser that you can't make async (e.g. event bubbling).
However, one of Repl.it's goal is to support every language ever existed so building and maintaining our own virtual machines would be quite an undertaking for our 3 person team.
What I'm hoping for is that we sometime soon leverage WASM to compile down an existing JS VM.
Cool stuff! I work with @jpolitz and @enum on the Stopify project as well.
Early on we also implemented a similar generator approach to what you described (as well as CPS). We found that it mostly worked, but had a few drawbacks. Specifically, generators change the type of instrumented functions, which makes it difficult to implement constructors and prototype inheritance, and they also break tail calls in environments that support them. More importantly for practical concerns, we found it to be much slower (at least 2x-3x) than the solution we came up with.
In collaboration with @jpolitz, we've been working on way to debug programs written in arbitrary source languages in the browser that you may find interesting. You can find a technology demo here:
Stopify uses existing compilers that produce JavaScript (e.g., ScalaJS, BuckleScript, etc.) We've tested with ten languages, five of which are on the website. There are three key pieces to Stopify: (1) first-class continuations
for JavaScript (warts included), (2) browser-specific optimizations, and (3) language-specific optimizations (i.e., many compilers emit a sane subset of JavaScript that Stopify can exploit to improve performance). We've conducted a
pretty extensive performance evaluation that we can also share. E.g., we've found that PyJs + Stopify can be as fast as Skulpt with suspensions.
I view it as a mild plus that the confusion around the name has educated so many about confectionery taxonomies.