Continuum - ES6 virtual machine built in ES3

David Bruant bruant.d at
Tue Dec 11 13:31:46 PST 2012

Le 11/12/2012 21:46, Brandon Benvie a écrit :
> - project
> - debugger
> npm module 'continuum'
> Continuum is a virtual machine for executing ES6 code (the spec is 
> rapidly iterating so many things need updating). It's written in ES3 
> and targets a baseline of IE8 (debugger included). With a small amount 
> of additional work it could run reliably in engines as old as IE6, but 
> this hasn't been a priority.
> Almost all ES6 features are supported to some degree: modules, 
> Proxy/Reflect, Map/Set/WeakMap, generators, 
> destructuring/spread/rest/default params, __proto__, classes, Symbols, 
> Typed Arrays/DataView (all features work in any host engine that can 
> run Continuum).
Awesome :-)

> The only remaining features which are unimplemented are tail call 
> optimization (incomplete and disabled pending some changes), array 
> comprehensions, generator expressions, and new parts of the binary 
> data API (structs, etc.). Some features are incomplete and potentially 
> buggy, especially ones which are completely new and have a lot of 
> surface area not covered by test262 (proxies
I've started a test suite at
It was just for me at first, so I started with QUnit (I'll probably 
change that eventually). My end goal is to write test for the internals 
of built-in algorithms; proxies exposes them, I'd like to be sure that 
there is some minimum test suite that shows spec deviations for these 
(and why not see if proxies make engines crash when applying built-in 
There is only one branch and I'm in the middle of a refactoring :-s
I think you can start with this commit 
until I'm done with the refactoring (then, I'll use different branches 
and be more clean in my commits and history)
Tests are aligned with the current direct proxies strawman. (not sure 
I'm 100% up-to-date when it comes to the enumerate trap signature, I'll 
have to check)

> generators especially). I intend to start creating test cases for 
> these features as soon as I finish fixing out the remaining test262 
> tests that Continuum fails.
I'd like to point out that I've sent feedback [1][2][3] after my work on 
the test suite. I'm more and more convinced that writing test suites is 
an excellent opportunity to see corners that weren't seen before. I'd 
say that this exercise is complementary to the spec editing work based 
on which Allen and wiki.ecmascript editors regularly sends feedback to 
the list too.
I've posted (and Andreas before me) about built-in algorithms being 
frozen as soon as proxies are released. I take writing tests for that as 
an opportunity to carefully review these algorithms and maybe suggest 
changes if applicable. I don't think anyone really want to spend time 
reading algorithms and imagining how proxies would interact with them. 
Writing tests is a good excuse to do this exercise.
And... there will be a test suite as outcome, but the way I see it, the 
process of writing the test suite is actually more important than the 
outcome itself.

So, yes, if you do want to write tests for any feature, I strongly 
encourage you to do so. I strongly encourage anyone reading this message 
to do so.



More information about the es-discuss mailing list