Planning for 1.0

59 views
Skip to first unread message

Ariya Hidayat

unread,
Aug 28, 2012, 8:58:19 PM8/28/12
to esp...@googlegroups.com
Folks,

Beside potential minor bug fixing, notably involving the syntax node
location, I don't think there will be major surgery needed anymore in
Esprima before reaching the ultimate first 1.0 release ever.

Things which I still plan to complete, but definitely are not showstoppers, are:
- full strict mode tolerance
- updating Escodegen
- updating Harmonizr

Depending on my luck, this should take no more than few weeks and then
I'll start creating a 1.0 branch to prepare for the ultimate 1.0
release.

As always, feedback is welcomed. Thank you!

Regards,


--
Ariya Hidayat, http://ariya.ofilabs.com
http://twitter.com/ariyahidayat

Yusuke Suzuki

unread,
Aug 29, 2012, 11:34:47 AM8/29/12
to esp...@googlegroups.com
Hello Ariya,

Beside potential minor bug fixing, notably involving the syntax node
location, I don't think there will be major surgery needed anymore in
Esprima before reaching the ultimate first 1.0 release ever.

Agreed.

- updating Escodegen

In escodegen, Robert's great contribution about minifying is done and current code state is stable.
I'll release 0.0.6. (currently 0.0.6-dev)

And I think issue 324 is a problem to solve for release 1.0.
After it is fixed, I think esprima is good enough to release it as 1.0.

Regards,
Yusuke Suzuki

Kris Kowal

unread,
Aug 29, 2012, 4:48:08 PM8/29/12
to esp...@googlegroups.com
I have been thinking about Harmonizr with regard to the module system.
One of the things that is weak at the moment are the linking
semantics.

The trick is that Harmony modules are not like CommonJS modules.
Imported and exported values are hoisted to a shared scope. Each
module would have (at compile time) a linking table mapping local free
variable names in a module to their corresponding slot in the shared
scope. Then, the linker would translate export statements to
assignments into properties of the shared scope. Import clauses
disappear in the harmonized output, except for an "if this module’s
harmonized function has not been executed yet, do so". The details of
the import clause are only important at time of analysis to build the
link table.

The other hitch is that, if you grow your working set, it would be
desirable to be able to link into the existing shared scope. To make
that possible the "shared" scope may have to be an object name space
instead.

// a
export var x;
x = 10;
// b
import {x: "y"} from "a";
y = 20;

// harmonized
var shared = {};
var modules = {};
modules.a = {factory: a};
function a() {
modules.a.exports = {};
if (!modules.b.exports) {
modules.b.factory();
}
modules.a.exports.x = 10;
}
modules.b = {factory: b};
function b() {
module.b.exports = {};
if (!modules.a.exports) {
modules.a.factory()
}
modules.a.exports.x = 20; // note the static translation from "y" to "x".
}

The the next hitch is how to avoid module name space collisions. I
think that can be accomplished by internally using a substring of a
consistent hash of the source module text in place of the "module
name". Soo "f0b4z" instead of "a", for example. With this strategy,
a working set can grow and still coordinate with modules that have
already been loaded and executed.

Kris Kowal

Ariya Hidayat

unread,
Aug 31, 2012, 11:38:18 PM8/31/12
to esp...@googlegroups.com

Might be useful to pull Jason into the Harmonizr discussion, maybe there is already some plan for this delicate module transpiling.

In addition, it could be useful to look at V8 code to see what it is being done there on the module handling. Unless of course there is another engine actively implementing it, too.

--
Ariya

Ariya Hidayat

unread,
Oct 2, 2012, 1:28:16 AM10/2/12
to esp...@googlegroups.com
Just some update.

> Things which I still plan to complete, but definitely are not showstoppers, are:
> - full strict mode tolerance
> - updating Escodegen
> - updating Harmonizr

The above items are all resolved.

There is still a corner-case with nested binary expression
(http://code.google.com/p/esprima/issues/detail?id=345). Due to our
design, this needs some nasty workaround. However, rest assured that
this technical debt will be paid in 1.1, hopefully with an improved
approach.

Yusuke Suzuki

unread,
Oct 2, 2012, 5:21:55 AM10/2/12
to esp...@googlegroups.com
Agreed. It's time to release 1.0 :)
--
Regards,
Yusuke Suzuki

Ariya Hidayat

unread,
Oct 5, 2012, 10:19:31 AM10/5/12
to esp...@googlegroups.com
I've created 1.0 branch so that we can think of new stuff for master
branch (upcoming 1.1).

I'll post some thoughts and my ideas about it in a separate thread.

Ariya Hidayat

unread,
Oct 22, 2012, 8:41:33 AM10/22/12
to esp...@googlegroups.com
I've tagged 1.0.0, published Node.js and Bower package for that.

Enjoy!
Reply all
Reply to author
Forward
0 new messages