jpolitz

> I assume this intended at a class which has already finished writing an AOT compiler and wants to build faster functions than you can derive at a compile time.

Quick answer just to this part: So the design challenge I was trying to solve here was doing AOT+JIT in one ugrad compilers class. This eats into some of the later assignments, but actually “worked”, in the sense that many students wrote first-call specialization.

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.

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.

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!