dcodeIO

Regarding collection of closure contexts: Seems the idea here is to pass around a closure context (containing both the function index and the lexical scope) instead of just a function...

Maybe one way to work around the allocation is to keep a singleton closure context per non-closure around in static memory. Like, if we know that the table has max...

Potential implementation idea: * A function reference is represented by a function table index currently. * Closures would be special function references with an attached context, means: managed allocations Problem:...

It'd cause the table to be 6,25% larger than it needs to be (every 16th element is the null function), but this is independent of how many closures there are...

Turns out that a clean way to represent closures isn't quite enough yet. There are various corner cases with phis (closure in one branch), loops (modifying a local before we...

Appears that the foremost building block we need there is another pass that finds out about captured locals before actually compiling the function. This way, we can allocate a single...

> you can get away with just per-closure environment capturing all necessary variables from all parent scopes That's the latest I had on my mind, yeah. As an example, if...

Indeed, at AS we are using the C-API directly. So far, I considered maintaining the accompanying JS+documentation as a nice-to-have for those within the community who rely on it. I...

> Maybe you're missing the bit where binaryen.js is not even compatible with what's in this repo's JS bindings ? that is definitely caused by the dual repos (and is...

There is no special handling for Wrappers, Any, Duration, Timestamp etc. currently. What could be done, though, is to set up [custom classes](https://github.com/dcodeIO/protobuf.js#using-custom-classes) for these types that are capable of...