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 h
> [1] http://wiki.ecmascript.org/doku.php?id=strawman:dicts [D.H. already
> mentioned that this proposal does not reflect his current thinking, so beware]
FWIW, I don't really know what my current thinking is. :)
Dave
___
es-discuss mailing list
es-di
On Oct 20, 2011, at 12:59 PM, Jorge wrote:
>>> assert_invariants();
>>> f(); //might suspend execution
>>> assert_invariants(); // perhaps yes, perhaps no. There's no guarantee
>>> either.
>>> return;
(Please trim cited text -- I know gmail hides it, which is a bug, but most mail
user agents sh
On 20/10/2011, at 18:38, Brendan Eich wrote:
> On Oct 20, 2011, at 6:44 AM, Jorge wrote:
>> On 19/10/2011, at 23:34, Brendan Eich wrote:
>>>
>>> The other objection is that (ignoring some evil native APIs such as sync
>>> XHR) JS has run-to-completion execution model now. You can model
>>>
>>> a
How does it fair on test262? http://test262.ecmascript.org/
--
kangax
On Wed, Oct 19, 2011 at 6:26 AM, Yusuke Suzuki wrote:
> 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.co
On Oct 20, 2011, at 12:31 AM, Andreas Rossberg wrote:
> (Mh, actually, could we
> even distinguish between function declerations and expression
> statements starting with a function expr in LALR(1), without heavy
> grammar transformation?)
To answer this question, there's no way to disambiguate
On Oct 20, 2011, at 6:44 AM, Jorge wrote:
> On 19/10/2011, at 23:34, Brendan Eich wrote:
>>
>> The other objection is that (ignoring some evil native APIs such as sync
>> XHR) JS has run-to-completion execution model now. You can model
>>
>> assert_invariants();
>> f();
>> assert_invariants_not
On Oct 20, 2011, at 12:31 AM, Andreas Rossberg wrote:
> One concern might be that we probably cannot make arrow notation (if
> we introduce it) a primary expression, and it might be confusing if
> they have different precedence.
We absolutely cannot and the strawman specifies the grammar fully:
On Thu, Oct 20, 2011 at 9:44 AM, Jorge wrote:
> On 19/10/2011, at 23:34, Brendan Eich wrote:
> >
> > The other objection is that (ignoring some evil native APIs such as sync
> XHR) JS has run-to-completion execution model now. You can model
> >
> > assert_invariants();
> > f();
> > assert_inva
On 19/10/2011, at 23:34, Brendan Eich wrote:
>
> The other objection is that (ignoring some evil native APIs such as sync XHR)
> JS has run-to-completion execution model now. You can model
>
> assert_invariants();
> f();
> assert_invariants_not_affected_by_f_etc();
>
> where "etc" means func
One concern might be that we probably cannot make arrow notation (if
we introduce it) a primary expression, and it might be confusing if
they have different precedence.
I also think it is easier to parse for the human reader when he sees
(function f() { ... })()
instead of
function f() { ..
11 matches
Mail list logo