Closed arjunguha closed 6 years ago
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.
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.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 const
s that remain---we can turn them into var
s. The newRTS
function implements the singleton pattern and the other two are trivially safe.
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?
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
.
Stopify w/ Pyret is fast enough for now.
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.
+1 for stopify in webworkers
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):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 tosuspend()
, the constructor encoding doesn't matter since the file does not usenew
, 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:
implicitApps.ts
requires NO changestsc
to buildstopify-continuations
, run./bin/stopify-continuations.js -t <transform> dist/src/runtime/implicitApps.ts dist/implicitApps.<transform>.js
exposeImplicitApps
to emit therequire()
only if--require-runtime
is true<script>
that loads the right implicitApps file.mustWebpack
instopify/src/index.ts
so that we don't webpack whenopts.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
andopts.hofs === 'fill
. However, I'm less certain about howeval
works and I would like to eliminate Webpack foreval
too.