On Oct 6, 2014 9:58 AM, Till Schneidereit t...@tillschneidereit.net
wrote:
On Mon, Oct 6, 2014 at 9:22 AM, Isiah Meadows impinb...@gmail.com
wrote:
Clearly, we still have a long way to go before beating a C++ parser.
Pretty interesting to think about, though.
This comparison, while quite
CC the list... :(
-- Forwarded message --
From: Isiah Meadows impinb...@gmail.com
Date: Mon, Oct 6, 2014 at 2:19 AM
Subject: Re: Throwing errors on mutating immutable bindings
To: Till Schneidereit t...@tillschneidereit.net
Thank you. I was looking for something I could
) + '
microseconds.');
```
On Mon, Oct 6, 2014 at 3:02 AM, Isiah Meadows impinb...@gmail.com wrote:
CC the list... :(
-- Forwarded message --
From: Isiah Meadows impinb...@gmail.com
Date: Mon, Oct 6, 2014 at 2:19 AM
Subject: Re: Throwing errors on mutating immutable bindings
To: Till
On Mon, Oct 6, 2014 at 9:22 AM, Isiah Meadows impinb...@gmail.com wrote:
Clearly, we still have a long way to go before beating a C++ parser.
Pretty interesting to think about, though.
This comparison, while quite informative, isn't a full answer to the
question at hand, for at least two
On Sun, Oct 5, 2014 at 7:24 AM, Isiah Meadows impinb...@gmail.com wrote:
If I can find a native parser (that only parses), I would run benchmarks.
Shouldn't take that long to time a few rounds of parsing a large library
like jQuery or React. I would be more than willing to accept pointers on
If I can find a native parser (that only parses), I would run benchmarks.
Shouldn't take that long to time a few rounds of parsing a large library
like jQuery or React. I would be more than willing to accept pointers on
where to find one.
I know one exists in Java (Closure Compiler), but I'm not
I mean that I wasn't thinking straight when I sent that. I'm incorrect
in every detail of that email.
On Thu, Oct 2, 2014 at 6:51 PM, Brendan Eich bren...@mozilla.org wrote:
Isiah Meadows wrote:
True, and I don't know of a decently fast ES3/5 parser.
What is your use-case? For a parser in
Isiah Meadows wrote:
I mean that I wasn't thinking straight when I sent that. I'm incorrect
in every detail of that email.
No worries -- I'm interested in parser benchmarks, both in-JS and
C++-to-the-metal. Anyone else have any?
/be
___
es-discuss
On 1 October 2014 16:09, Erik Arvidsson erik.arvids...@gmail.com wrote:
The static error is problematic. I'm pretty sure that engines that do lazy
parsing of functions is not going to report static errors before doing a
full parse of the function.
Well, it is no harder than reporting reference
On 1 October 2014 20:32, Jason Orendorff jason.orendo...@gmail.com wrote:
I think there is a way that the error could occur at runtime even in
all-strict-mode code: when a new const is added at toplevel in a
second script.
script
use strict;
function f(value) { x = value; }
On 2 October 2014 09:24, Andreas Rossberg rossb...@google.com wrote:
On 1 October 2014 20:32, Jason Orendorff jason.orendo...@gmail.com wrote:
I think there is a way that the error could occur at runtime even in
all-strict-mode code: when a new const is added at toplevel in a
second script.
On Thu, Oct 2, 2014 at 12:22 AM, Andreas Rossberg rossb...@google.com
wrote:
On 1 October 2014 16:09, Erik Arvidsson erik.arvids...@gmail.com wrote:
The static error is problematic. I'm pretty sure that engines that do
lazy
parsing of functions is not going to report static errors before
On 2 October 2014 10:45, Mark Miller erig...@gmail.com wrote:
On Thu, Oct 2, 2014 at 12:22 AM, Andreas Rossberg rossb...@google.com
wrote:
On 1 October 2014 16:09, Erik Arvidsson erik.arvids...@gmail.com wrote:
The static error is problematic. I'm pretty sure that engines that do
lazy
On 2 October 2014 16:06, Andreas Rossberg rossb...@google.com wrote:
So, yes, please let us remove the requirement to make const
assignments an early error. A single, relatively unimportant
diagnostics like that is not worth the considerable complication for
VMs, especially given that all
On 2 October 2014 17:17, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
I believe that the module champions have always wanted static unresolvablse
reference rejection to be part of the module semantics. But we've never had
actual specification for that semantics.
Yes, I had always hoped
On Oct 2, 2014, at 8:31 AM, Andreas Rossberg rossb...@google.com wrote:
On 2 October 2014 17:17, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
I believe that the module champions have always wanted static unresolvablse
reference rejection to be part of the module semantics. But we've never
on mutating immutable bindings
On 2 October 2014 17:17, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
I believe that the module champions have always wanted static
unresolvablse reference rejection to be part of the module semantics. But
we've never had actual specification for that semantics.
Yes
Isiah Meadows wrote:
True, and I don't know of a decently fast ES3/5 parser.
What is your use-case? For a parser in JS, is
http://marijnhaverbeke.nl/blog/acorn.html too slow? For C++ hand-coded
parser, what's your not-decently-fast benchmark basis code?
ES6 will be even more complicated,
The static error is problematic. I'm pretty sure that engines that do lazy
parsing of functions is not going to report static errors before doing a
full parse of the function.
I think we need to either enforce this or remove this restriction. Anything
in between will lead to inconsistent behavior
JSC does lazy parsing of nested functions and we have no problem reporting
static errors, so i’m not sure what you believe is the problem here.
—Oliver
On Oct 1, 2014, at 7:09 AM, Erik Arvidsson erik.arvids...@gmail.com wrote:
The static error is problematic. I'm pretty sure that engines
On Wed, Oct 1, 2014 at 8:20 AM, Oliver Hunt oli...@apple.com wrote:
JSC does lazy parsing of nested functions and we have no problem reporting
static errors, so i’m not sure what you believe is the problem here.
Hi Oliver,
First, I agree with you. This shouldn't be a problem.
However, both
On Oct 1, 2014, at 7:09 AM, Erik Arvidsson wrote:
The static error is problematic. I'm pretty sure that engines that do lazy
parsing of functions is not going to report static errors before doing a full
parse of the function.
I think we need to either enforce this or remove this
On Oct 1, 2014, at 8:39 AM, Mark S. Miller wrote:
...
I was with you until you got to the following point
If there is an intervening with or sloppy direct eval, then there is not a
statically apparent assignment to a const variable. Since this can only occur
in sloppy code anyway, it
On Wed, Oct 1, 2014 at 5:39 PM, Mark S. Miller erig...@google.com wrote:
On Wed, Oct 1, 2014 at 8:20 AM, Oliver Hunt oli...@apple.com wrote:
JSC does lazy parsing of nested functions and we have no problem
reporting static errors, so i’m not sure what you believe is the problem
here.
Hi
Good point. If we can require all such assignments to be rejected
statically, why is a runtime assignment to a const variable even possible?
Can't we just assert that this cannot occur?
On Wed, Oct 1, 2014 at 8:59 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Oct 1, 2014, at 8:39 AM,
On Oct 1, 2014, at 9:05 AM, Mark S. Miller wrote:
Good point. If we can require all such assignments to be rejected statically,
why is a runtime assignment to a const variable even possible? Can't we just
assert that this cannot occur?
The runtime cases I meant are the ones you mentioned.
On Oct 1, 2014, at 9:43 AM, Oliver Hunt wrote:
On Oct 1, 2014, at 9:05 AM, Mark S. Miller erig...@google.com wrote:
Good point. If we can require all such assignments to be rejected
statically, why is a runtime assignment to a const variable even possible?
Can't we just assert that
On Wed, Oct 1, 2014 at 9:15 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Oct 1, 2014, at 9:05 AM, Mark S. Miller wrote:
Good point. If we can require all such assignments to be rejected
statically, why is a runtime assignment to a const variable even possible?
Can't we just assert
On Oct 1, 2014, at 10:30 AM, Mark Miller wrote:
On Wed, Oct 1, 2014 at 9:15 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Oct 1, 2014, at 9:05 AM, Mark S. Miller wrote:
Good point. If we can require all such assignments to be rejected
statically, why is a runtime
I think there is a way that the error could occur at runtime even in
all-strict-mode code: when a new const is added at toplevel in a
second script.
script
use strict;
function f(value) { x = value; }
/script
script
use strict;
const x = 0;
f(1);
Right.
Need a complete semantics: static and runtime. News at 11,
/be
Jason Orendorff wrote:
I think there is a way that the error could occur at runtime even in
all-strict-mode code: when a new const is added at toplevel in a
second script.
script
use strict;
function
Yup, and we've talked about this at TC39 meetings. We need a
simple-enough static analysis, and runtime errors for the residue that
escapes that analysis. I hope this is not controversial!
/be
Erik Arvidsson wrote:
The static error is problematic. I'm pretty sure that engines that do
lazy
Hi all,
In the current draft, I see 2 different places where assigning to an immutable
binding ('const') throws an error:
1) Dynamically throwing a TypeError in SetMutableBinding,
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-declarative-environment-records-setmutablebinding-n-v-s
33 matches
Mail list logo
