Re: Formalize error.stack?
It probably makes sense to converge on a common string format. However, I agree with some of the previous replies: if the main motivation for standardising stack traces is to make them processable, then we should focus on introducing a structured format. /Andreas On 12 November 2013 21:33, Oliver Hunt oli...@apple.com wrote: Righto, filed https://bugs.webkit.org/show_bug.cgi?id=124220 —Oliver On Nov 12, 2013, at 12:30 PM, Mark Miller erig...@gmail.com wrote: FWIW, the code I linked to, which arv refers to, when it finds itself on SM, normalizes the SM error stack string to approx v8's format. But the more important part of the answer is the parsed form provided by getCWStack. On Tue, Nov 12, 2013 at 12:20 PM, Oliver Hunt oli...@apple.com wrote: Righto, do we know whether Carakan/V8’s text or SM’s text is preferred? Currently it seems like JSC’s is a little bit weird compare to others, and as i’ve said earlier i’m happy to change it to match another engine (we all have the same info in varying ways, so we can all technically produce the same view in our .stack string) —Oliver On Nov 12, 2013, at 11:17 AM, Erik Arvidsson erik.arvids...@gmail.com wrote: On Tue, Nov 12, 2013 at 12:35 PM, Oliver Hunt oli...@apple.com wrote: The only formatting requirement for the stack property is that if it is present, it must be a string. No. There is a lot of code out there that parses this string and depend on the format. See Mark's reply for one such case. —Oliver On Nov 12, 2013, at 9:23 AM, Erik Arvidsson erik.arvids...@gmail.com wrote: When I started investigating this I had the hope that stack could be standardized. However, the format of the string is cannot be changed without breaking the web so the way forward is to introduce a new property name. But since we are introducing a new property name we should return structured data instead of a plain old string. I haven't had the time to work on this since my initial analysis of the state of the stack property. On Mon, Nov 11, 2013 at 7:51 PM, John Barton johnjbar...@google.com wrote: Note that in Chrome the devtools are remote and error.stack is a getter which issues a remote method call to the backend. Only when the stack property is accessed will the internal representation be converted to a string. Anything else is too expensive. A plain JS object format would be much more useful for development tools developers. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Text by me above is hereby placed in the public domain Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak callbacks?
On 11/12/13 11:07 PM, David Bruant wrote: I understand the need to know when a promise has an unhandled error at development time, I'm less clear on why you need to know it at runtime. Why would you do with this information? handle the error? The same thing that sites (e.g. Facebook) do with window.onerror: phone home to the server about the bug so it can actually get fixed. -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak callbacks?
On Tue, Nov 12, 2013 at 8:07 PM, David Bruant bruan...@gmail.com wrote: Le 12/11/2013 13:42, Kris Kowal a écrit : One of the concerns with promises is that they consume exceptions that may or may not be handled. ... I understand the need to know when a promise has an unhandled error at development time, I'm less clear on why you need to know it at runtime. Why would you do with this information? handle the error? If you think of wrapping promises in weakrefs, why not just add error handling? To me, it looks like the same amount of effort. Kris and David highlight a critical issue for using promises in professional applications: changes to source, including eg library version changes, lead to failures that are not detected at development time and thus ship to users where they are (um) exceptionally difficult to sort out. I don't understand why this issue isn't a show stopper for systemic promises proposals. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
ECMAScript error sink (was: Weak callbacks?)
Le 13/11/2013 06:15, Boris Zbarsky a écrit : On 11/12/13 11:07 PM, David Bruant wrote: I understand the need to know when a promise has an unhandled error at development time, I'm less clear on why you need to know it at runtime. Why would you do with this information? handle the error? The same thing that sites (e.g. Facebook) do with window.onerror: phone home to the server about the bug so it can actually get fixed. I'm sympathetic with this use case, but Weakrefs seem like the wrong tool to solve this problem. Wrapping every single promise in case one ended up failing in an unexpected way feels way too expensive. There should be a sort of error sink feature instead. The browser has window.onerror for historical reasons, Node.js introduced Domains and Domain#intercept [1] for that reason IIUC. Isn't it the sign that ECMAScript should have this feature built-in? A global sink has something absurd to it, what about adding an error sink feature to module loaders? cc'ing ES6 Module folks Ideally, the ECMAScript error sink would handled both uncaught thrown errors and unhandled promise errors. David [1] http://nodejs.org/api/domain.html ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ECMAScript error sink (was: Weak callbacks?)
On 11/13/13 10:58 AM, David Bruant wrote: I'm sympathetic with this use case, but Weakrefs seem like the wrong tool to solve this problem. I think I agree on that. Ideally, the ECMAScript error sink would handled both uncaught thrown errors and unhandled promise errors. Defining unhandled promise error is not trivial, actually, unless you just mean rejected promise that no one ever sets any reject callbacks on. -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ECMAScript error sink
Le 13/11/2013 08:11, Boris Zbarsky a écrit : On 11/13/13 10:58 AM, David Bruant wrote: I'm sympathetic with this use case, but Weakrefs seem like the wrong tool to solve this problem. I think I agree on that. Ideally, the ECMAScript error sink would handled both uncaught thrown errors and unhandled promise errors. Defining unhandled promise error is not trivial, actually, unless you just mean rejected promise that no one ever sets any reject callbacks on. That would be my definition. no one ever sets any reject callback on is itself undecidable (the ever part), but I feel it works well enough in practice. Cases where it doesn't, people have memory leaks. Domain#intercept which looks at the Node error convention (error in async callback first argument) certainly suffer from the same issue, but looks practical enough. I lack the experience with Node domains. If some have it, it'd be interesting to share it. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: ECMAScript error sink
From: es-discuss es-discuss-boun...@mozilla.org on behalf of David Bruant bruan...@gmail.com Domain#intercept which looks at the Node error convention (error in async callback first argument) certainly suffer from the same issue, but looks practical enough. I lack the experience with Node domains. If some have it, it'd be interesting to share it. `Domain.prototype.intercept` is a rarely-used feature of domains. Wrapping your callbacks in `domain.intercept` before passing them to a callback-accepting function is akin to attaching an error handler to a promise that always puts the error inside an error-storage box (domain) which you or someone else can centrally handle later. I do not think it's particularly relevant to error-handling discussions. The value of domains comes in them being a global switch you can turn on that allows all errors thrown within a given request/response cycle to be caught in a single place. (With certain problematic edge-case exceptions to this rule.) This allows you to associate uncaught errors with the request/response cycle in question, as opposed to the browser's `window.onerror` where you get no real context as to what caused the exception. This is especially important in Node where the same function (e.g. a HTTP server's request handler) can be called thousands of times at once, with different data, so the stack trace alone is not useful. More detail in [a presentation I gave](http://www.slideshare.net/domenicdenicola/domains-20010482) a while back. Domains are considered something of a band-aid and are being subsumed into a more general async listener API in Node.js 0.12. The async listener API gives you the ability to add AOP-style before/after handlers for any async operation in Node.js. (I believe libraries like Google's Closure accomplish this in the browser already, by wrapping all async APIs.) Domains will be re-implemented on top of async listeners for backward compatibility, but async listener is the new primitive for async interception of the type that domains were a special case of. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ECMAScript error sink (was: Weak callbacks?)
On Nov 13, 2013, at 7:58 AM, David Bruant wrote: ... The browser has window.onerror for historical reasons, Node.js introduced Domains and Domain#intercept [1] for that reason IIUC. Isn't it the sign that ECMAScript should have this feature built-in? A global sink has something absurd to it, what about adding an error sink feature to module loaders? cc'ing ES6 Module folks Uncaught exception handling doesn't seem like something that is naturally associated with a module loader or a Realm as a call stacks can wind through function objects that originated from many different Realms. It actually seems like something that would more naturally be associated with a turn. Perhaps anything that explicitly schedules a microtask should have the ability to associate an unhandled exception handler with it. Or, alternatively consider that every turn must begin by calling a function, so perhaps such a handler could just be represented as a function property. Engine uncaught handling would get the 'uncaughtException' property of the base function of the current stack. The implementation of 'uncaughtException' in Function.prototype would be a primitive that aborts the turn. Any function that might be used as a base functioin could over-ride 'uncaughtException' to do its own handling and perhaps finishing by doing a super call to the default. Ideally, the ECMAScript error sink would handled both uncaught thrown errors and unhandled promise errors. At least at the implementation level, unhandled promise error seem very different from unhandled exceptions. In fact, such an promise error may well represent a handled exception. I wonder, if a time-out model might not be a better one for dealing with the promises case. Allen [1] http://nodejs.org/api/domain.html ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ECMAScript error sink
On Wed, Nov 13, 2013 at 8:20 AM, David Bruant bruan...@gmail.com wrote: Le 13/11/2013 08:11, Boris Zbarsky a écrit : On 11/13/13 10:58 AM, David Bruant wrote: I'm sympathetic with this use case, but Weakrefs seem like the wrong tool to solve this problem. I think I agree on that. Ideally, the ECMAScript error sink would handled both uncaught thrown errors and unhandled promise errors. Defining unhandled promise error is not trivial, actually, unless you just mean rejected promise that no one ever sets any reject callbacks on. That would be my definition. no one ever sets any reject callback on is itself undecidable (the ever part), but I feel it works well enough in practice. Hi David, I don't understand what you mean by it above. Because the question is undecidable, we need approximations. The two approximations that seem good are those that never have false negatives with few false positives, and those that never have false positives with few false negatives. They would bound the undecidable question from above and below. AFAICT, these are the two we've already discussed: * The console approach Domenic has previously described captures the approximation no one has yet set any reject callback on. * The finalization-based approach Kris explained captures the approximation no one can even set any reject callback on because the promise is unreachable. * And finally, the .done() operation provides even better accuracy at the price of asking programmers to more explicitly state their intent. Do you have in mind some way to better approximate the undecidable question than these? Do you have some way to do as well as, or better than, the second bullet without observing GC decisions? Cases where it doesn't, people have memory leaks. Domain#intercept which looks at the Node error convention (error in async callback first argument) certainly suffer from the same issue, but looks practical enough. I lack the experience with Node domains. If some have it, it'd be interesting to share it. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ECMAScript error sink
On Wed, Nov 13, 2013 at 9:25 AM, Mark S. Miller erig...@google.com wrote: On Wed, Nov 13, 2013 at 8:20 AM, David Bruant bruan...@gmail.com wrote: Le 13/11/2013 08:11, Boris Zbarsky a écrit : On 11/13/13 10:58 AM, David Bruant wrote: I'm sympathetic with this use case, but Weakrefs seem like the wrong tool to solve this problem. I think I agree on that. Ideally, the ECMAScript error sink would handled both uncaught thrown errors and unhandled promise errors. Defining unhandled promise error is not trivial, actually, unless you just mean rejected promise that no one ever sets any reject callbacks on. That would be my definition. no one ever sets any reject callback on is itself undecidable (the ever part), but I feel it works well enough in practice. Hi David, I don't understand what you mean by it above. Because the question is undecidable, we need approximations. The two approximations that seem good are those that never have false negatives with few false positives, and those that never have false positives with few false negatives. They would bound the undecidable question from above and below. AFAICT, these are the two we've already discussed: * The console approach Domenic has previously described captures the approximation no one has yet set any reject callback on. * The finalization-based approach Kris explained captures the approximation no one can even set any reject callback on because the promise is unreachable. can even set should be can ever set. * And finally, the .done() operation provides even better accuracy at the price of asking programmers to more explicitly state their intent. Do you have in mind some way to better approximate the undecidable question than these? Do you have some way to do as well as, or better than, the second bullet without observing GC decisions? Cases where it doesn't, people have memory leaks. Domain#intercept which looks at the Node error convention (error in async callback first argument) certainly suffer from the same issue, but looks practical enough. I lack the experience with Node domains. If some have it, it'd be interesting to share it. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
ECMAScript Error Sink
Hi Mark,
The only approximation that seems acceptable to me is one that (a) never
has false negatives, and (b) provides a simple way for developers to
receive notification on and fix false positives.
Over in Dart they have implemented zones.
http://api.dartlang.org/dart_async.html
{ zen }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ECMAScript Error Sink
The only approximation that seems acceptable to me is one that (a) never
has false negatives, and (b) provides a simple way for developers to
receive notification on and fix false positives.
Basic sysadmin stuff.
To finish the thought, `done` and `WeakRefs` fail (a), and console-only
solutions fail (b) in production environments.
{ zen }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: [Json] JSON: remove gap between Ecma-404 and IETF draft
On Nov 13, 2013, at 1:27 PM, Paul Hoffman wrote: no hat On Nov 13, 2013, at 12:24 PM, Joe Hildebrand (jhildebr) jhild...@cisco.com wrote: We would also need to change section 8.1 according to the mechanism that was previously proposed: 00 00 00 xx UTF-32BE 00 xx ?? xx UTF-16BE xx 00 00 00 UTF-32LE xx 00 xx ?? UTF-16LE xx xx ?? ?? UTF-8 in order to account for strings at the top level whose first character has a codepoint greater than 127. A string at the top level of a JSON text still needs to start with an ASCII character, so the logic is still fine, I believe. Carsten's point about whitespace is more problematic. Does the ECMA-404 definition of a JSON text allow it to start with one (or more) whitespace characters? The text in that document says: . . . A JSON text is a sequence of tokens formed from Unicode code points that conforms to the JSON value grammar. The set of tokens includes six structural tokens, strings, numbers, and three literal name tokens. . . . Insignificant whitespace is allowed before or after any token. . . . It would be nice if ECMA-404 was clearer on this, given that the racetrack illustrations show everything other than the whitespace. In specific, it would be good to know whether or not the racetrack for value in Section 5 is meant to have optional whitespace at the left and right to match the above text. If TC39 could say for certain on that, it would be useful to the community. Yes, leading white space is allowed: The set of tokens includes the six structural tokens, *strings*, *numbers*, ... (emphasis added) Insignificant whitespace is allowed before or after any token The elements matched by the value production are all tokens (or productions that begin and end with a token) so whitespace can occur to the left or right of any value Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Rev21 ES6 Draft now available
Nit: 9.1.10 [[Delete]] (P) Steps 5 6 should be steps 4a 4b (lost an indent) On Fri, Nov 8, 2013 at 12:25 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: PDFs and .doc file available at http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#november_8_2013_draft_rev_21 New in this revision: • Updated Module Syntax and static semantics • Scripts no longer may contain import statements • Specified how to determine if a call is in tail position • The call and apply functions now internally do tail calls to the target function • Tweaked the new operator so it will work in tail position • Eliminated the [[Invoke]] MOP operation • Calling the next method of an completed generator returns a “done” result instead of throwing • The length property of bound functions is now configurable/non-writable • Clarified requirements of String localeCompare when no language sensitive comparison support is available. • Tweaked the ordering of a few steps in Array.from to enable self-hosting using for-of • Added ToInt8 and similar abstract operation • Defined name property of %TypedArray% and the individual typed array constructors • Significant fixed to yield * evaluation semantics • Fixed handling of identifier ‘yield’ in generator function parameter lists • A little static semantic cleanup making sure that FunctionDeclarations and GeneratorDeclarations have the same top level scoping rules ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Specification of use before declaration errors
Wait, so is there no variable shadowing allowed then?
13.1.1http://people.mozilla.org/~jorendorff/es6-draft.html#sec-block-static-semantics-early-errors
Static Semantics: Early Errors
Block : { StatementList }
* It is a Syntax Error if the LexicallyDeclaredNames of StatementList
contains any duplicate entries.
* It is a Syntax Error if any element of the LexicallyDeclaredNames of
StatementList also occurs in the VarDeclaredNames of StatementList.
StatementList can contain Blocks whose LexicallyDeclaredNames and
VarDeclaredNames algorithms return the values for their StatementLists, so it
recursively collects the names from all nested lexical and var declarations.
It looks like VarDeclaredNames is missing a definition for VariableStatement
because I can't see any way for the bound names of a VariableStatement to get
added to VarDeclaredNames lists.
But barring for the moment that I cannot find an algorithm definition that adds
BoundNames of a VariableStatement to VarDeclaredNames, this second early error
bullet implies that shadowing of bound names is not allowed at all.
Is this correct?
Ian
From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com]
Sent: Friday, November 8, 2013 4:16 PM
To: Ian Halliday
Cc: es-discuss@mozilla.org
Subject: Re: Specification of use before declaration errors
On Nov 8, 2013, at 3:35 PM, Ian Halliday wrote:
Hello es-discuss,
I'm having difficulty figuring out where the ES6 draft spec specifies that a
use before declaration error should be thrown. My last understanding of the
temporal dead zone was that ECMAScript would always issue a use before
declaration error at runtime, regardless whether it can be statically
determined or not. However it seems like the evaluation semantics of var
declarations, for example, do not lead to any line that throws a ReferenceError.
That is, consider this code:
function f() {
{
var x = 5;
let x;
declaring the same name using a let and a var is an early error:
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-block-static-semantics-early-errors
or for the function level
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-function-definitions-static-semantics-early-errors
}
}
f();
I think the var declaration creates a binding for x in the function's lexical
environment, but then binds to the x in the block's environment for the
initialization. As such, the initialization should throw a use before
declaration error. But this is what I cannot find in the spec. Maybe I am
wrong about the semantics here?
because an early error exists, the surround script or module is never evaluated.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Specification of use before declaration errors
On Nov 13, 2013, at 3:41 PM, Ian Halliday wrote:
Wait, so is there no variable shadowing allowed then?
this is saying that things like the following are illegal:
{var x;
let x;
}
But shadowing, like the following is fine:
var x;
{let x;
}
13.1.1 Static Semantics: Early Errors
Block : { StatementList }
· It is a Syntax Error if the LexicallyDeclaredNames of StatementList
contains any duplicate entries.
· It is a Syntax Error if any element of the LexicallyDeclaredNames
of StatementList also occurs in the VarDeclaredNames ofStatementList.
StatementList can contain Blocks whose LexicallyDeclaredNames and
VarDeclaredNames algorithms return the values for their StatementLists, so it
recursively collects the names from all nested lexical and var declarations.
It looks like VarDeclaredNames is missing a definition for VariableStatement
because I can’t see any way for the bound names of a VariableStatement to get
added to VarDeclaredNames lists.
But barring for the moment that I cannot find an algorithm definition that
adds BoundNames of a VariableStatement to VarDeclaredNames, this second early
error bullet implies that shadowing of bound names is not allowed at all.
Is this correct?
Ian
From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com]
Sent: Friday, November 8, 2013 4:16 PM
To: Ian Halliday
Cc: es-discuss@mozilla.org
Subject: Re: Specification of use before declaration errors
On Nov 8, 2013, at 3:35 PM, Ian Halliday wrote:
Hello es-discuss,
I’m having difficulty figuring out where the ES6 draft spec specifies that a
“use before declaration” error should be thrown. My last understanding of
the temporal dead zone was that ECMAScript would always issue a “use before
declaration” error at runtime, regardless whether it can be statically
determined or not. However it seems like the evaluation semantics of var
declarations, for example, do not lead to any line that throws a
ReferenceError.
That is, consider this code:
function f() {
{
var x = 5;
let x;
declaring the same name using a let and a var is an early error:
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-block-static-semantics-early-errors
or for the function level
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-function-definitions-static-semantics-early-errors
}
}
f();
I think the var declaration creates a binding for x in the function’s lexical
environment, but then binds to the x in the block’s environment for the
initialization. As such, the initialization should throw a “use before
declaration” error. But this is what I cannot find in the spec. Maybe I am
wrong about the semantics here?
because an early error exists, the surround script or module is never
evaluated.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Specification of use before declaration errors
Oh, is shadowing a let declaration with a var declaration a syntax error?
E.g.
{
let x;
{
var x;
}
}
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Ian
Halliday
Sent: Wednesday, November 13, 2013 4:14 PM
To: Allen Wirfs-Brock
Cc: es-discuss@mozilla.org
Subject: RE: Specification of use before declaration errors
Then for 13.1.8 shouldn't there be something like this
StatementListItem : Statement
1. If Statement is a Block then return a new empty List.
2. Else return VarDeclaredNames of Statement
defined in order to prevent the var names from spreading into enclosing blocks?
I might be misunderstanding VarDeclaredNames. I am guessing that it should be
a collection of all the names declared via var declaration statements, i.e.
VariableStatement, but there isn't a definition of VarDeclaredNames for
VariableStatement.
13.1.8http://people.mozilla.org/~jorendorff/es6-draft.html#sec-block-static-semantics-vardeclarednames
Static Semantics: VarDeclaredNames
See also:
13.0.1http://people.mozilla.org/~jorendorff/es6-draft.html#sec-statement-semantics-static-semantics-vardeclarednames,
13.5.1http://people.mozilla.org/~jorendorff/es6-draft.html#sec-if-statement-static-semantics-vardeclarednames,
13.6.1.1http://people.mozilla.org/~jorendorff/es6-draft.html#sec-do-while-statement-static-semantics-vardeclarednames,
13.6.2.1http://people.mozilla.org/~jorendorff/es6-draft.html#sec-while-statement-static-semantics-vardeclarednames,
13.6.3.1http://people.mozilla.org/~jorendorff/es6-draft.html#sec-for-statement-static-semantics-vardeclarednames,
13.6.4.3http://people.mozilla.org/~jorendorff/es6-draft.html#sec-for-in-and-for-of-statements-static-semantics-vardeclarednames,
13.10.2http://people.mozilla.org/~jorendorff/es6-draft.html#sec-with-statement-static-semantics-vardeclarednames,
13.11.4http://people.mozilla.org/~jorendorff/es6-draft.html#sec-switch-statement-static-semantics-vardeclarednames,
13.12.2http://people.mozilla.org/~jorendorff/es6-draft.html#sec-labelled-statements-static-semantics-vardeclarednames,
13.14.2http://people.mozilla.org/~jorendorff/es6-draft.html#sec-try-statement-static-semantics-vardeclarednames,
14.1.11http://people.mozilla.org/~jorendorff/es6-draft.html#sec-function-definitions-static-semantics-vardeclarednames,
14.4.10http://people.mozilla.org/~jorendorff/es6-draft.html#sec-generator-function-definitions-static-semantics-vardeclarednames,
14.5.14http://people.mozilla.org/~jorendorff/es6-draft.html#sec-class-definitions-static-semantics-vardeclarednames,
15.1.0.12http://people.mozilla.org/~jorendorff/es6-draft.html#sec-module-semantics-static-semantics-vardeclarednames,
15.2.5http://people.mozilla.org/~jorendorff/es6-draft.html#sec-scripts-static-semantics-vardeclarednames.
Block : { }
1. Return a new empty
Listhttp://people.mozilla.org/~jorendorff/es6-draft.html#sec-list-and-record-specification-type.
StatementList : StatementList StatementListItem
1. Let names be VarDeclaredNames of StatementList.
2. Append to names the elements of the VarDeclaredNames of
StatementListItem.
3. Return names.
StatementListItem : Declaration
1. Return a new empty
Listhttp://people.mozilla.org/~jorendorff/es6-draft.html#sec-list-and-record-specification-type.
From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com]
Sent: Wednesday, November 13, 2013 3:49 PM
To: Ian Halliday
Cc: es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
Subject: Re: Specification of use before declaration errors
On Nov 13, 2013, at 3:41 PM, Ian Halliday wrote:
Wait, so is there no variable shadowing allowed then?
this is saying that things like the following are illegal:
{var x;
let x;
}
But shadowing, like the following is fine:
var x;
{let x;
}
13.1.1http://people.mozilla.org/~jorendorff/es6-draft.html#sec-block-static-semantics-early-errors
Static Semantics: Early Errors
Block : { StatementList }
* It is a Syntax Error if the LexicallyDeclaredNames of StatementList
contains any duplicate entries.
* It is a Syntax Error if any element of the LexicallyDeclaredNames of
StatementList also occurs in the VarDeclaredNames ofStatementList.
StatementList can contain Blocks whose LexicallyDeclaredNames and
VarDeclaredNames algorithms return the values for their StatementLists, so it
recursively collects the names from all nested lexical and var declarations.
It looks like VarDeclaredNames is missing a definition for VariableStatement
because I can't see any way for the bound names of a VariableStatement to get
added to VarDeclaredNames lists.
But barring for the moment that I cannot find an algorithm definition that adds
BoundNames of a VariableStatement to VarDeclaredNames, this second early error
bullet implies that shadowing of bound names is not allowed at all.
Is this correct?
Ian
From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com]
Sent: Friday, November 8, 2013
Re: Specification of use before declaration errors
On Nov 13, 2013, at 4:18 PM, Ian Halliday wrote:
Oh, is “shadowing” a let declaration with a var declaration a syntax error?
E.g.
yes, although strictly speaking it is the hoisting of the var over the let that
is an error. Amounts to the same thing.
{
let x;
{
var x;
}
}
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Ian
Halliday
Sent: Wednesday, November 13, 2013 4:14 PM
To: Allen Wirfs-Brock
Cc: es-discuss@mozilla.org
Subject: RE: Specification of use before declaration errors
Then for 13.1.8 shouldn’t there be something like this
StatementListItem : Statement
1. If Statement is a Block then return a new empty List.
2. Else return VarDeclaredNames of Statement
defined in order to prevent the var names from spreading into enclosing
blocks?
I might be misunderstanding VarDeclaredNames. I am guessing that it should
be a collection of all the names declared via var declaration statements,
i.e. VariableStatement, but there isn’t a definition of VarDeclaredNames for
VariableStatement.
13.1.8 Static Semantics: VarDeclaredNames
See also: 13.0.1, 13.5.1, 13.6.1.1, 13.6.2.1, 13.6.3.1, 13.6.4.3, 13.10.2,
13.11.4, 13.12.2, 13.14.2, 14.1.11, 14.4.10, 14.5.14, 15.1.0.12, 15.2.5.
Block : { }
1. Return a new empty List.
StatementList : StatementList StatementListItem
1. Let names be VarDeclaredNames of StatementList.
2. Append to names the elements of the VarDeclaredNames of
StatementListItem.
3. Return names.
StatementListItem : Declaration
1. Return a new empty List.
From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com]
Sent: Wednesday, November 13, 2013 3:49 PM
To: Ian Halliday
Cc: es-discuss@mozilla.org
Subject: Re: Specification of use before declaration errors
On Nov 13, 2013, at 3:41 PM, Ian Halliday wrote:
Wait, so is there no variable shadowing allowed then?
this is saying that things like the following are illegal:
{var x;
let x;
}
But shadowing, like the following is fine:
var x;
{let x;
}
13.1.1 Static Semantics: Early Errors
Block : { StatementList }
· It is a Syntax Error if the LexicallyDeclaredNames of StatementList
contains any duplicate entries.
· It is a Syntax Error if any element of the LexicallyDeclaredNames
of StatementList also occurs in the VarDeclaredNames ofStatementList.
StatementList can contain Blocks whose LexicallyDeclaredNames and
VarDeclaredNames algorithms return the values for their StatementLists, so it
recursively collects the names from all nested lexical and var declarations.
It looks like VarDeclaredNames is missing a definition for VariableStatement
because I can’t see any way for the bound names of a VariableStatement to get
added to VarDeclaredNames lists.
But barring for the moment that I cannot find an algorithm definition that
adds BoundNames of a VariableStatement to VarDeclaredNames, this second early
error bullet implies that shadowing of bound names is not allowed at all.
Is this correct?
Ian
From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com]
Sent: Friday, November 8, 2013 4:16 PM
To: Ian Halliday
Cc: es-discuss@mozilla.org
Subject: Re: Specification of use before declaration errors
On Nov 8, 2013, at 3:35 PM, Ian Halliday wrote:
Hello es-discuss,
I’m having difficulty figuring out where the ES6 draft spec specifies that a
“use before declaration” error should be thrown. My last understanding of
the temporal dead zone was that ECMAScript would always issue a “use before
declaration” error at runtime, regardless whether it can be statically
determined or not. However it seems like the evaluation semantics of var
declarations, for example, do not lead to any line that throws a
ReferenceError.
That is, consider this code:
function f() {
{
var x = 5;
let x;
declaring the same name using a let and a var is an early error:
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-block-static-semantics-early-errors
or for the function level
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-function-definitions-static-semantics-early-errors
}
}
f();
I think the var declaration creates a binding for x in the function’s lexical
environment, but then binds to the x in the block’s environment for the
initialization. As such, the initialization should throw a “use before
declaration” error. But this is what I cannot find in the spec. Maybe I am
wrong about the semantics here?
because an early error exists, the surround script or module is never
evaluated.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: [Json] JSON: remove gap between Ecma-404 and IETF draft
On Wed, Nov 13, 2013 at 3:51 PM, Joe Hildebrand (jhildebr) jhild...@cisco.com wrote: that all software implementations which receive the un-prefixed text will not generate parse errors. perhaps: ...all conformant software ... Mark https://google.com/+MarkDavis *— Il meglio è l’inimico del bene —* ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Should arrow functions have arguments or capture arguments bindings
The draft spec has a note in 9.2.13 Function Declaration Instantiation about
arrow functions and arguments:
Issure: should concise methods also not get an arguments object?
From rev16 it appears.
Section 9.2.13 also has a large banner stating that it is old and will change
re concensus made in the Sept 2013 TC39 meeting.
I can't see any mention of arguments and arrow functions in the Sept 2013
meeting notes so is it safe to assume this behavior hasn't changed? Given the
note is this still an open issue?
If arguments is not added to the arrow function's var bindings, does this mean
an arrow function should capture variables named arguments from the enclosing
scope?
E.g.
function f () {
var x = () = arguments; // captures f()'s implicit arguments
{
let arguments;
var y = () = arguments; // captures lexical local variable
}
}
Ian
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: [Json] JSON: remove gap between Ecma-404 and IETF draft
On Nov 13, 2013, at 3:51 PM, Joe Hildebrand (jhildebr) wrote: On 11/13/13 3:47 PM, John Cowan co...@mercury.ccil.org wrote: It's not clear that 404 disallows it, since 404 is defined in terms of characters, and a BOM is not a character but an out-of-band signal. However, for example, a conforming implementation of the ECMAScript JSON.parse function would reject any string passed to it that starts with a U+FFEF code point because the unquoted occurrence of that code point does not conform to the ECMA-252, 5th Edition or Ecma-404 JSON grammar. In order to be successfully processed, that code point would have to be stripped from the string prior to calling JSON.parse. Allen Agree. However, that signal would be a part of the 4627bis octet stream, so a little interop guidance would likely be useful. Something like: Some producers of JSON produce JSON-text that starts with a redundant U+FEFF (ZERO WIDTH NO-BREAK SPACE, previously known as BYTE ORDER MARK) with the ostensible purpose of signaling the encoding of the text to follow. Since JSON has other mechanisms to determine encoding, this is not required. Receiving applications MAY safely ignore this initial character without generating an error. Implementations that do not send U+FEFF are interoperable in the sense that all software implementations which receive the un-prefixed text will not generate parse errors. Isn't it an interooperbility issue that many receiving applications do not ignore it. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
