new ECMA262 5.1 engine
How does it fair
I got reply from Mr. Fugate, used test262 commad-line runner for lv5, got some bugs in engine (JSON quote process and RegExp escape had a bug. now fixed). Thanks for this great test suite!
Now, some test262 test cases are failed, but these failures have reasons.
First I found test262 bugs. So I heard from Mr. Fugate that bugs can be reported at bugs.ecmascript.org, then reported them.
ecmascript#215 // misspelling "grammar", sorry... ecmascript#216, ecmascript#217, ecmascript#218
And, I tried to implement RegExp.prototype.compile, but ES5 and ES3 not defined its standard behavior and I thought compile method is changing RegExp#source / #global / #ignoreCase / #multiline which writable attribute are false and breaking ES5 PropertyDescriptor system, so I created template, but not implemented it. Constellation/iv/commit/7cbc22474ada389a3ac8ab5d3ad5df38bed8a583
And some test cases (about 20 cases?) expect the enumeration order of Object properties. (not reported yet) For example, chapter15/15.2/15.2.3/15.2.3.14/15.2.3.14-2-8 expects Object.keys Array order. But I didn't implement ordered properties because ES5 didn't specify it. So some tests are sometimes failed (if order happened to be expected, test cases are passed...)
And S15.10.2.13_A1_T16 is failed. But backreference in ClassEscape is not accepted, and my engine recognize [¥12-¥14] as the range that is from 12 to 14. Do you think about it? I passively think that this regexp raises SyntaxError in ES5 scope. ES5 allows engine to extend RegExp syntax, but extended behavior is not ensured by ES5. es5.github.com/#x15.10.2.19
But other tes262 test cases are passed! result is this (python tools/packaging/test262.py --command ~/dev/iv/obj/lv5/lv5 --full-summary > result)
If you try to run it, you can build lv5 Constellation/iv/wiki/lv5 and run test cases test262:command
If you find bugs, I would appreciate it if you would report it.
Thanks.
Wow! That is quite some work that you've done here. Implementing an ES5 interpreter and contributions to test262. Well, congratulations and thank you !
David
Le 21/10/2011 07:17, Yusuke Suzuki a écrit :
On Oct 20, 2011, at 10:17 PM, Yusuke Suzuki wrote:
And, I tried to implement RegExp.prototype.compile, but ES5 and ES3 not defined its standard behavior and I thought compile method is changing RegExp#source / #global / #ignoreCase / #multiline which writable attribute are false and breaking ES5 PropertyDescriptor system, so I created template, but not implemented it. Constellation/iv/commit/7cbc22474ada389a3ac8ab5d3ad5df38bed8a583
contributions to test262
test262 is great, thanks!
Oh, Thanks. This is very good document. I saw harmony:regexp_match_web_reality and strawman:match_web_reality_spec . And I've fixed for my RegExp runtime to accept examples in it.
BTW, I thought that the example in strawman:match_web_reality_spec exec(/(?=a)+/, ""); should return false. Is it right?
On Sat, Oct 22, 2011 at 5:30 PM, Yusuke Suzuki <utatane.tea at gmail.com> wrote:
BTW, I thought that the example in strawman:match_web_reality_spec exec(/(?=a)+/, ""); should return false. Is it right?
In ES5, it should be a syntax error. The positive look-ahead is an Assertion, not an Atom, and quantifiers can only be applied to Atoms. In ES3, the regexp will not match the string literal. Putting quantifiers on look-aheads is always unnecessary in ECMAScript, since it's always equivalent to either requiring zero or one match of the lookahead.
The "web reality" is that browser RegExp engines follow the ES3 syntax for this case.
In ES5, it should be a syntax error. The positive look-ahead is an Assertion, not an Atom, and quantifiers can only be applied to Atoms. In ES3, the regexp will not match the string literal. Putting quantifiers on look-aheads is always unnecessary in ECMAScript, since it's always equivalent to either requiring zero or one match of the lookahead.
The "web reality" is that browser RegExp engines follow the ES3 syntax for this case.
OK, thanks! I'll create 2 parsers, for web-reality and ES5 strict.
Thanks.
On Sun, Oct 23, 2011 at 6:03 AM, Lasse Reichstein < reichsteinatwork at gmail.com> wrote:
On Sat, Oct 22, 2011 at 5:30 PM, Yusuke Suzuki <utatane.tea at gmail.com>
wrote:
BTW, I thought that the example in strawman:match_web_reality_spec exec(/(?=a)+/, ""); should return false. Is it right?
In ES5, it should be a syntax error. The positive look-ahead is an Assertion, not an Atom, and quantifiers can only be applied to Atoms. In ES3, the regexp will not match the string literal. Putting quantifiers on look-aheads is always unnecessary in ECMAScript, since it's always equivalent to either requiring zero or one match of the lookahead.
The "web reality" is that browser RegExp engines follow the ES3 syntax for this case.
/L
On Sat, Oct 22, 2011 at 5:04 AM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
On Oct 20, 2011, at 10:17 PM, Yusuke Suzuki wrote:
And, I tried to implement RegExp.prototype.compile, but ES5 and ES3 not defined its standard behavior and I thought compile method is changing RegExp#source / #global / #ignoreCase / #multiline which writable attribute are false and breaking ES5 PropertyDescriptor system, so I created template, but not implemented it.
Constellation/iv/commit/7cbc22474ada389a3ac8ab5d3ad5df38bed8a583
see
Hello.
I wrote new ECMA262 5.1 full support engine "iv / lv5" in C++. This is highly inspired from JSC, V8 and SpiderMonkey. (especially JSC)
Constellation/iv
This aims at most precise engine to ECMA262 5.1 specification. (like the great engine,)
I read ECMA262 and wanted precise engine to understand this spec, so I created.
features,
all ECMA262 5.1th features (strict mode, direct call / indirect call to eval, PropertyDescriptor, early errors, Object.prototype.toString.call(null / undefined), Object extras, Array extras, etc.) BESEN // for example, directive prologure including octal value and strict directive is rejected. function test() { "¥02"; "use strict"; } stack VM JSC like bytecode based PIC ES5 oriented structures in C++ (PropertyDescriptor, Attributes(Enumerable, Writable, Configurable)) optimized JSArray (using vector and hash map) but this array implements full features of ECMA262 5.1th. for example,
with throw = true is called. } catch (e) { print(e); } ary[3] = 2; // of cource ... print(ary.length); // 2;
minimum source code 2 engines, VM and AST Interpreter. we can switch it by command line option. bytecode based backtrack RegExp (read re1 report and source code to study VM based RegExp runtime, and implemented it) ES5 oriented optimization for example, if I get "eval" keyword in strict mode, don't make variable dynamic (hold on heap variable with offset access) because direct call to eval in strict mode cannot create new variable in upper local call site environment.
At first, I created AST Interpreter (named "teleporter") which algorithm is just the same to ECMA262 specification. And after it is done, I created optimized bytecode VM (named "railgun"). These 2 engines are abstracted, so we can switch it at runtime. ('--interp option') AST Interpreter is very slow, but this source code is exactly the same to ECMA262 specification algorithm, so this may be interesting for spec readers.
And, SunSpider is available for this engine, so, you can bench it. (sorry, probably slow, because of no JIT...)
I'm planning to create own GC (now using BoehmGC library), and create JIT module.
Finally, I'm respecting JSC, V8, SpiderMonkey, BESEN implementors great works.
Thanks.
Hello. I wrote new ECMA262 5.1 full support engine "iv / lv5" in C++. This is highly inspired from JSC, V8 and SpiderMonkey. (especially JSC) https://github.com/Constellation/iv This aims at most precise engine to ECMA262 5.1 specification. (like the great engine,) I read ECMA262 and wanted precise engine to understand this spec, so I created. features, all ECMA262 5.1th features (strict mode, direct call / indirect call to eval, PropertyDescriptor, early errors, Object.prototype.toString.call(null / undefined), Object extras, Array extras, etc.) BESEN // for example, directive prologure including octal value and strict directive is rejected. function test() { "¥02"; "use strict"; } stack VM JSC like bytecode based PIC ES5 oriented structures in C++ (PropertyDescriptor, Attributes(Enumerable, Writable, Configurable)) optimized JSArray (using vector and hash map) but this array implements full features of ECMA262 5.1th. for example, var ary = [0, 1]; Object.defineProperty(ary, 'length', { writable : false }); ary.length = 4; // of cource, in strict mode, this raises error. print(ary.length); // 2 try { ary.push(2); // throw TypeError, because [DefineOwnProperty] with throw = true is called. } catch (e) { print(e); } ary[3] = 2; // of cource ... print(ary.length); // 2; minimum source code 2 engines, VM and AST Interpreter. we can switch it by command line option. bytecode based backtrack RegExp (read re1 report and source code to study VM based RegExp runtime, and implemented it) ES5 oriented optimization for example, if I get "eval" keyword in strict mode, don't make variable dynamic (hold on heap variable with offset access) because direct call to eval in strict mode cannot create new variable in upper local call site environment. At first, I created AST Interpreter (named "teleporter") which algorithm is just the same to ECMA262 specification. And after it is done, I created optimized bytecode VM (named "railgun"). These 2 engines are abstracted, so we can switch it at runtime. ('--interp option') AST Interpreter is very slow, but this source code is exactly the same to ECMA262 specification algorithm, so this may be interesting for spec readers. And, SunSpider is available for this engine, so, you can bench it. (sorry, probably slow, because of no JIT...) I'm planning to create own GC (now using BoehmGC library), and create JIT module. Finally, I'm respecting JSC, V8, SpiderMonkey, BESEN implementors great works. Thanks.