Eliminate Webpack

[arjunguha]

We should simply stop using Webpack. Here is my plan using the --es es5 flag. If this works, I suspect we can apply the same methodology to all flags that require webpacking.

The --es es5 flag adds the following line to the top of the generated file (https://github.com/plasma-umass/Stopify/blob/master/stopify-continuations/src/exposeImplicitApps.ts#L27):

$i = require('stopify-continuations/dist/src/runtime/implicitApps')

Currently, we resolve this require using Webpack, using Stopify as a plugin. This ensures that the implicitApps file is compiled with exactly the same flags as the main program.

Note that we only need implicitApps to use the same transformation (-t) as the main program. We don't need to insert calls to suspend(), the constructor encoding doesn't matter since the file does not use new, the arguments-object aliasing is not an issue, and so on.

So, here is what I propose we do: precompile implicitApps (for each value of -t) and webpack the generated code so that it exposes the module as a variable $i, which is what the rest of the system already expects. So, a user who is using --es es5 will have to insert a second <script> tag to load the module. In fact, it can be loaded by default; and simply remain unused.

Here are the changes that I think are necessary:

• [x] Cleanup Stopify generated header as described below
• [x] implicitApps.ts requires NO changes
• [x] After running tsc to build stopify-continuations, run ./bin/stopify-continuations.js -t <transform> dist/src/runtime/implicitApps.ts dist/implicitApps.<transform>.js
• [x] Modify exposeImplicitApps to emit the require() only if --require-runtime is true
• [ ] Modify the browser benchmarking harness to insert a <script> that loads the right implicitApps file.
• [ ] Modify the definition of mustWebpack in stopify/src/index.ts so that we don't webpack when opts.es === 'es5'

@baxtersa and @rachitnigam do you see any issues here? Do you think this approach will work with the other flags that require Webpack? I suspect that this will work fine for opts.getters and opts.hofs === 'fill. However, I'm less certain about how eval works and I would like to eliminate Webpack for eval too.

[rachitnigam]

• Will work fine for opts.getters especially because the getters runtime does not require stopification.
• eval bundles the whole compiler using browserify. It won't be affected.

One suggestion -- We should do this on the features branch because it implements eval. If there are issue with eval they will be fixed before this is merged in.

[baxtersa]

• eval doesn't require webpacking because the stopify compiler itself does not get stopified. This is technically a problem because the stopify compiler running in-browser will lock up the page and not be interruptable, but I think bootstrapping the stopify compiler with stopify is beyond what we'll ever do.
• hofs will be fine with this approach, but may need to be curated for new/arguments flags to be safe.

[arjunguha]

One other issue. All Stopify-generated files begin with this header and it cannot be duplicated:

const $__T = stopify;
const $__R = $__T.newRTS('lazy');
const $handleNew = $__R.handleNew.bind($__R);
const captureCC = $__R.captureCC.bind($__R);
const suspendCC = $__R.suspendCC;
const RV_SENTINAL = {};
const EXN_SENTINAL = {}

• I think the sentinels can be folded into the runtime system (i.e., we would write stopify.RV_SENTINAL and stopify.EXN_SENTINAL.)

• I think that captureCC and suspendCC don't need to be named. We should just delete them.

• The three consts that remain---we can turn them into vars. The newRTS function implements the singleton pattern and the other two are trivially safe.

[arjunguha]

I want @rachitnigam and @jpolitz to confirm that stopifying the Stopify compiler is not something that matters for Pyret. Is Stopify fast enough on a per-function basis, which is how you guys use it in Pyret?

[rachitnigam]

compileFunction on the features branch makes sure that these headers are not added to top of the program. We can use that to compile the the require'd files and assume that the main file declares these const.

[rachitnigam]

Stopify w/ Pyret is fast enough for now.

[jpolitz]

I still feel like Stopify could cause unresponsive script warnings in the browser when working on large files, right?

In any event, it might be easier to make Stopify faster and figure out how to stick compilation in a web worker (since that's a fully serialized interface) than to stopify stopify.

[rachitnigam]

+1 for stopify in webworkers