Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add detection for whether we are on an active Stopify stack
Adds a stackActive field to abstractRuntime that tracks whether the JavaScript stack is currently using Stopified frames, and exposes it through isRunning() on abstractRuntime. The use case for this, beyond it being a likely-useful utility, is writing polyfills for HOFs that can switch on and off depending on if they can expect to capture or not. We've done some of this work for Pyret (https://github.com/brownplt/pyret-lang/blob/8e0ce78fb0ca1c10bcc06dfcaeb534d0ae2c02e4/src/runtime/hof-array-polyfill.ts#L347) because the Pyret runtime co-exists on a page with regular old React code. Because everything in React and in the Stopified runtime is getting asynchronously chopped up and scheduled all over the place, and because we want JS arrays to be arrays whether in the stopify runtime or the page runtime, it's useful to have polyfills that automatically do the right thing. This avoids these problems: - If using the default array polyfill strategy from Stopify, non-stopified code can get access to arrays with stopified map/filter/fold. Say that's called in some `didComponentUpdate` or other scheduled React event – now it's not on a Stopify stack and lots of e.g. uncaught Captures result. It is really, really hard to remember that every array may or may not be from the Stopify runtime and have a different prototype. - When calling into Stopified code, it's natural to want to pass in “regular” arrays. It's also hard to remember and design APIs around introducing wrapping on these as they *enter* stopified code. - The flag lets us handle cases like: - A didComponentUpdate starts a Pyret evaluation for e.g. rendering a Pyret value to a React element, which calls back into some Stopified Pyret code. This goes in a suitable wrapper. - That code suspends for whatever reason, yielding control back to didComponentUpdate, which uses e.g. map/filter/fold. The map/filter/fold in didComponentUpdate will correctly use the plain, un-instrumented map/filter/fold. - The Stopified code resumes in the next turn and does map/filter/fold in the dynamic extent of the Pyret code. This correctly uses the stopified versions of the HOFs.
- Loading branch information