Ecma 402 (i18n API) v2.0 features list
https://docs.google.com/spreadsheet/ccc?key=0AhsGcaqNtRMpdC1FVEZOZ2tqdWRHdWdtRkMyaFM3VGc#gid=0 Please take a look at the document. Add new or comment on existing features. I'll send a calendar invite shortly. -- Nebojša Ćirić ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
repeated parameter names and default values
Consider
function f(a, b=a, a=3, c=a) {
return a+ +b+ +c
}
console.log(f(1));
Based upon the conclusions about argument binding at the recent TC39 meeting
this will display:
3 1 3
Any disagreement of this?
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: repeated parameter names and default values
it would be stupid to code like that but it makes sense since it has
basically always been like that :)
function f(a) {
// var a superflous ... still works
var a, b = a, a = 3, c = a;
return a+ +b+ +c;
}
On Thu, Sep 27, 2012 at 5:19 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
Consider
function f(a, b=a, a=3, c=a) {
return a+ +b+ +c
}
console.log(f(1));
Based upon the conclusions about argument binding at the recent TC39
meeting this will display:
3 1 3
Any disagreement of this?
Allen
___
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: repeated parameter names and default values
On Sep 27, 2012, at 9:31 AM, Andrea Giammarchi wrote: it would be stupid to code like that but it makes sense since it has basically always been like that :) A big part of of my job is specifying what stupid code does. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: repeated parameter names and default values
I did not mean to offend anyone ... it just looked weirdest, non-sense, function contract, ever :D Apologies and thanks for describing **even** these details in specifications, appreciated! On Thu, Sep 27, 2012 at 5:41 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Sep 27, 2012, at 9:31 AM, Andrea Giammarchi wrote: it would be stupid to code like that but it makes sense since it has basically always been like that :) A big part of of my job is specifying what stupid code does. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Позив: Ecma 402 v2.0 meeting у пет 5. окт 10:00 - 16:50 (es-discuss@mozilla.org)
BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VEVENT DTSTART:20121005T17Z DTEND:20121005T235000Z DTSTAMP:20120927T164527Z ORGANIZER:mailto:c...@google.com UID:5bd4p7dr7hf722cif4014ki...@google.com ATTENDEE;CUTYPE=RESOURCE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE;C N=MTV-1225-2-Robotnik (10) GVC;X-NUM-GUESTS=0:mailto:google.com_726f6f6d5f6 d74765f313232355f325f726f626f746e6...@resource.calendar.google.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE ;X-NUM-GUESTS=0:mailto:c...@google.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=es-discuss@mozilla.org;X-NUM-GUESTS=0:mailto:es-discuss@mozilla.org CREATED:20120927T155809Z DESCRIPTION:Discuss what we want to include into v2.0 version of the API.\n \nFor agenda items please take a look at the document https://docs.google.c om/spreadsheet/ccc?key=0AhsGcaqNtRMpdC1FVEZOZ2tqdWRHdWdtRkMyaFM3VGc#gid=0\n \nAdd new or comment on existing features.\n\nThe address of the meeting is :\n1225 Charleston Rd\,\nMountain View\, CA 94043\n\nTeleconference info:\n US Toll free:1 866 457.4646\nParticipant passcode:15242605 then #\n\nWe hav e 10 seats in the room (we never needed more)\, but please reply if you are planning to come in person so I can organize bigger room if necessary.\n\n Погледајте догађај на http://www.google.com/calendar/event?action=VIEWeid= NWJkNHA3ZHI3aGY3MjJjaWY0MDE0a2ltaWcgZXMtZGlzY3Vzc0Btb3ppbGxhLm9yZwtok=MTUj Y2lyYUBnb29nbGUuY29tYzUxMDhkYjYwMzFiYzU5MmQzYmU0M2E3ZGU4NTI1YjA0ZjM0NGI4ZQ ctz=America/Los_Angeleshl=sr. LAST-MODIFIED:20120927T164526Z LOCATION:MTV-1225-2-Robotnik (10) GVC SEQUENCE:0 STATUS:CONFIRMED SUMMARY:Ecma 402 v2.0 meeting TRANSP:OPAQUE END:VEVENT END:VCALENDAR invite.ics Description: application/ics ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: repeated parameter names and default values
...this is how I discovered that, in non-strict mode, it's possible to
define a function where 2 arguments have the same name...
Le 27/09/2012 18:19, Allen Wirfs-Brock a écrit :
Consider
function f(a, b=a, a=3, c=a) {
The most positive adjective I can find to describe this like is:
confusing.
If I'm ever in a team where a dev writes such a line, I will kill this
dev with my bare hands :-)
When writing 'c=a', what was the intention of the developer? Maybe the
third arg has been renamed to 'a' by mistake during a refactoring,
introducing a subtle bug.
When using the same argument name several times with default values,
what about throwing an SyntaxError at parse time regardless of
strictness? It would follow what's been done with strict mode.
Also, is there really a value in being able reuse a previous argument to
define the value of another argument?
The idea of for the second argument, use its value unless it's
undefined in which case, reuse the value of the first argument smells
like poorly designed code or API, but I'm curious if some can show a
case where it's legitimate.
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Позив: Ecma 402 v2.0 meeting у пет 5. окт 10:00 - 16:50 (es-discuss@mozilla.org)
To translate parts in Serbian: Meeting is 10/5/2012, 10am - 4:50pm. The rest is hopefully readable to everybody :) 27. септембар 2012. 09.45, Nebojša Ćirić c...@google.com је написао/ла: више детаља »https://www.google.com/calendar/event?action=VIEWeid=NWJkNHA3ZHI3aGY3MjJjaWY0MDE0a2ltaWcgZXMtZGlzY3Vzc0Btb3ppbGxhLm9yZwtok=MTUjY2lyYUBnb29nbGUuY29tYzUxMDhkYjYwMzFiYzU5MmQzYmU0M2E3ZGU4NTI1YjA0ZjM0NGI4ZQctz=America/Los_Angeleshl=sr Ecma 402 v2.0 meeting Discuss what we want to include into v2.0 version of the API. For agenda items please take a look at the document https://docs.google.com/spreadsheet/ccc?key=0AhsGcaqNtRMpdC1FVEZOZ2tqdWRHdWdtRkMyaFM3VGc#gid=0 Add new or comment on existing features. The address of the meeting is: 1225 Charleston Rd, Mountain View, CA 94043 Teleconference info: US Toll free:1 866 457.4646 Participant passcode:15242605 then # We have 10 seats in the room (we never needed more), but please reply if you are planning to come in person so I can organize bigger room if necessary. *Када* пет 5. окт 10:00 – 16:50 Пацифичко време *Где* MTV-1225-2-Robotnik (10) GVC (мапаhttp://maps.google.com/maps?q=MTV-1225-2-Robotnik+(10)+GVChl=sr ) *Календар* es-discuss@mozilla.org *Ко* • Nebojša Ćirić– организатор • es-discuss@mozilla.org Идете ли? ***Даhttps://www.google.com/calendar/event?action=RESPONDeid=NWJkNHA3ZHI3aGY3MjJjaWY0MDE0a2ltaWcgZXMtZGlzY3Vzc0Btb3ppbGxhLm9yZwrst=1tok=MTUjY2lyYUBnb29nbGUuY29tYzUxMDhkYjYwMzFiYzU5MmQzYmU0M2E3ZGU4NTI1YjA0ZjM0NGI4ZQctz=America/Los_Angeleshl=sr- Мождаhttps://www.google.com/calendar/event?action=RESPONDeid=NWJkNHA3ZHI3aGY3MjJjaWY0MDE0a2ltaWcgZXMtZGlzY3Vzc0Btb3ppbGxhLm9yZwrst=3tok=MTUjY2lyYUBnb29nbGUuY29tYzUxMDhkYjYwMzFiYzU5MmQzYmU0M2E3ZGU4NTI1YjA0ZjM0NGI4ZQctz=America/Los_Angeleshl=sr- Неhttps://www.google.com/calendar/event?action=RESPONDeid=NWJkNHA3ZHI3aGY3MjJjaWY0MDE0a2ltaWcgZXMtZGlzY3Vzc0Btb3ppbGxhLm9yZwrst=2tok=MTUjY2lyYUBnb29nbGUuY29tYzUxMDhkYjYwMzFiYzU5MmQzYmU0M2E3ZGU4NTI1YjA0ZjM0NGI4ZQctz=America/Los_Angeleshl=sr ***још опција »https://www.google.com/calendar/event?action=VIEWeid=NWJkNHA3ZHI3aGY3MjJjaWY0MDE0a2ltaWcgZXMtZGlzY3Vzc0Btb3ppbGxhLm9yZwtok=MTUjY2lyYUBnb29nbGUuY29tYzUxMDhkYjYwMzFiYzU5MmQzYmU0M2E3ZGU4NTI1YjA0ZjM0NGI4ZQctz=America/Los_Angeleshl=sr Позив из Google календара https://www.google.com/calendar/ Ову е-поруку добијате на налог es-discuss@mozilla.org зато што сте учесник овог догађаја. Да бисте престали да добијате будућа обавештења за овај догађај, одбијте овај догађај. Осим тога, можете да се пријавите за Google налог на адреси https://www.google.com/calendar/ и да контролишете подешавања обавештења за цео календар. -- Nebojša Ćirić ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: repeated parameter names and default values
Le 27/09/2012 18:41, Allen Wirfs-Brock a écrit : On Sep 27, 2012, at 9:31 AM, Andrea Giammarchi wrote: it would be stupid to code like that but it makes sense since it has basically always been like that :) A big part of of my job is specifying what stupid code does. I'm begging, please throw early errors as much as you can! There is no reason for the language to encourage stupid or confusing code. Default arg values are a convenience introduced to improve readability. It's been introduced after the experience of functions starting with several x = x || v lines. I wish it was kept to that and not introduce new ways to write confusing code. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: repeated parameter names and default values
On Sep 27, 2012, at 9:45 AM, David Bruant bruan...@gmail.com wrote:
...this is how I discovered that, in non-strict mode, it's possible to
define a function where 2 arguments have the same name...
Le 27/09/2012 18:19, Allen Wirfs-Brock a écrit :
Consider
function f(a, b=a, a=3, c=a) {
The most positive adjective I can find to describe this like is:
confusing.
If I'm ever in a team where a dev writes such a line, I will kill this
dev with my bare hands :-)
When writing 'c=a', what was the intention of the developer? Maybe the
third arg has been renamed to 'a' by mistake during a refactoring,
introducing a subtle bug.
When using the same argument name several times with default values,
what about throwing an SyntaxError at parse time regardless of
strictness? It would follow what's been done with strict mode.
I actually like this, it simplifies the semantics if you say using default
arguments disallows duplicate names. This I think is a livable restriciton as
allowing duplicate arguments is basically just a backwards compat feature (so
obviously doesn't effect code using defaults).
I kind of like the idea of disallowing shadowing of argument names if defaults
are used as well, but I'm not sure if that would be as low risk to
comprehension of behaviour.
--Oloier
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: repeated parameter names and default values
On Thu, Sep 27, 2012 at 11:19 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
function f(a, b=a, a=3, c=a) {
return a+ +b+ +c
}
console.log(f(1));
Based upon the conclusions about argument binding at the recent TC39 meeting
this will display:
3 1 3
Not having been at the meeting, I had a little trouble coming up with
a desugaring where this worked. Is this the idea?
function f(a, b, a, c) {
var %args = a copy of arguments;
a = %args[0];
b = %args[1] === void 0 ? a : %args[1];
a = %args[2] === void 0 ? 3 : %args[2];
c = %args[3] === void 0 ? a : %args[3];
return a+ +b+ +c;
}
(Of course I understand it won't be specified in terms of desugaring
but through changes to 10.5.3, Function Declaration Instantiation).
For what it’s worth, I’m with David and Oliver: by all means, just
make that a SyntaxError.
-j
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: repeated parameter names and default values
On Thu, Sep 27, 2012 at 9:41 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Sep 27, 2012, at 9:31 AM, Andrea Giammarchi wrote: it would be stupid to code like that but it makes sense since it has basically always been like that :) A big part of of my job is specifying what stupid code does. Although Allen does so mostly for non-security reasons, I'll take this moment to make a security point: Normal non-defensive programming generally seeks to avoid edge cases, and especially edge cases where platforms are likely to differ. Attackers see such edge cases as opportunities. Whereas a correct program should work on all conforming platforms, an attack is successful even if it only succeeds on one supported platform. Therefore, defensive programs, though they should still stay away from edge conditions for the functionality they provide, must worry about and defend themselves against all the possible adversary behaviors that these edge conditions might enable. Thus, a language that supports defensive programming needs this kind of careful attention to stupid edge conditions. This is not to argue for or against any specifics of this proposal. Allen ___ 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: repeated parameter names and default values
Another:
The notes from last week's meeting said WRT function parameter bindings:
Conclusion/Resolution
- `var` bindings and are in scope within the function
- cannot use `let` to shadow a parameter
- defaults can refer to any top level binding
Using the above guidance, consider this one:
function test1(b=g) [
function g() {};
return typeof g + + typeof b;
}
console.log(test1());
presumably, this produces: function function
Which means that g is instantiated and initialized prior to apply the defaults
to the parameters.
Now consider:
function test2(g,b=g) [
function g() {};
return typeof g + + typeof b;
}
console.log(test2());
By the same logic, this presumably must also produce: function function
So how about:
console.log(test2(1));
Is it: function number or function function or number number
In ES5,
function test3(g) [
function g() {};
return typeof g;
}
console.log(test3(1));
produces function, so the number number alternative doesn't seem plausible.
In EX5, nested function declarations over-write parameters that share the same
name.
function number may seem reasonable for the second call of test2 but that
seems inconsistent with the first call and with test1.
So, it seems that nested function declarations must be instantiated and bound
before parameter instantiation/default value initialization and that parameters
that share a name with a such function declaration do not get reinitialized
(with either an argument or default value) during parameter instantiation.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: repeated parameter names and default values
as described here
function f(a) {
// var a superflous ... still works
var a, b = a, a = 3, c = a;
return a+ +b+ +c;
}
same / equivalent result
On Thu, Sep 27, 2012 at 6:09 PM, Jason Orendorff
jason.orendo...@gmail.comwrote:
On Thu, Sep 27, 2012 at 11:19 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
function f(a, b=a, a=3, c=a) {
return a+ +b+ +c
}
console.log(f(1));
Based upon the conclusions about argument binding at the recent TC39
meeting this will display:
3 1 3
Not having been at the meeting, I had a little trouble coming up with
a desugaring where this worked. Is this the idea?
function f(a, b, a, c) {
var %args = a copy of arguments;
a = %args[0];
b = %args[1] === void 0 ? a : %args[1];
a = %args[2] === void 0 ? 3 : %args[2];
c = %args[3] === void 0 ? a : %args[3];
return a+ +b+ +c;
}
(Of course I understand it won't be specified in terms of desugaring
but through changes to 10.5.3, Function Declaration Instantiation).
For what it’s worth, I’m with David and Oliver: by all means, just
make that a SyntaxError.
-j
___
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: repeated parameter names and default values
On Sep 27, 2012, at 10:03 AM, Oliver Hunt wrote:
On Sep 27, 2012, at 9:45 AM, David Bruant bruan...@gmail.com wrote:
...this is how I discovered that, in non-strict mode, it's possible to
define a function where 2 arguments have the same name...
Le 27/09/2012 18:19, Allen Wirfs-Brock a écrit :
Consider
function f(a, b=a, a=3, c=a) {
The most positive adjective I can find to describe this like is:
confusing.
If I'm ever in a team where a dev writes such a line, I will kill this
dev with my bare hands :-)
When writing 'c=a', what was the intention of the developer? Maybe the
third arg has been renamed to 'a' by mistake during a refactoring,
introducing a subtle bug.
When using the same argument name several times with default values,
what about throwing an SyntaxError at parse time regardless of
strictness? It would follow what's been done with strict mode.
I actually like this, it simplifies the semantics if you say using default
arguments disallows duplicate names. This I think is a livable restriciton
as allowing duplicate arguments is basically just a backwards compat feature
(so obviously doesn't effect code using defaults).
I kind of like the idea of disallowing shadowing of argument names if
defaults are used as well, but I'm not sure if that would be as low risk to
comprehension of behavior.
My original intent was to apply such rules and the current spec. draft actually
has some of these restrictions. However, those parts were written before 1JS
emerged and the consensus around 1JS seems to be try to gracefully extend the
current ES5 semantics to encompass such new feature without early error
restrictions.
Also, at the last meeting there was some significant push back about the
load-time costs (startup latency) of early error detection.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: repeated parameter names and default values
quoting myself: Apologies and thanks for describing **even** these details in specifications, appreciated! as summary: I know this is a must have too :-) On Thu, Sep 27, 2012 at 6:10 PM, Mark S. Miller erig...@google.com wrote: On Thu, Sep 27, 2012 at 9:41 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Sep 27, 2012, at 9:31 AM, Andrea Giammarchi wrote: it would be stupid to code like that but it makes sense since it has basically always been like that :) A big part of of my job is specifying what stupid code does. Although Allen does so mostly for non-security reasons, I'll take this moment to make a security point: Normal non-defensive programming generally seeks to avoid edge cases, and especially edge cases where platforms are likely to differ. Attackers see such edge cases as opportunities. Whereas a correct program should work on all conforming platforms, an attack is successful even if it only succeeds on one supported platform. Therefore, defensive programs, though they should still stay away from edge conditions for the functionality they provide, must worry about and defend themselves against all the possible adversary behaviors that these edge conditions might enable. Thus, a language that supports defensive programming needs this kind of careful attention to stupid edge conditions. This is not to argue for or against any specifics of this proposal. Allen ___ 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: repeated parameter names and default values
Allen Wirfs-Brock wrote: So, it seems that nested function declarations must be instantiated and bound before parameter instantiation/default value initialization and that parameters that share a name with a such function declaration do not get reinitialized (with either an argument or default value) during parameter instantiation. Yes, this was what I remember us agreeing to the other week (was it last week? A blur...). It's the simpler desugaring wins case. Parameters are var-like and defaulting happens in the body. Separately, I agree with David, Oliver, Jason, Mark and probably everyone that new syntax can mean new checks pulled in from strict mode. Duplicate formal parameters with defaulting? Error! We did this in SpiderMonkey for duplicate formals + destructuring, and the same argument applies there. I don't remember what our default parameter impl does with dups, though. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: repeated parameter names and default values
Allen Wirfs-Brock wrote: My original intent was to apply such rules and the current spec. draft actually has some of these restrictions. However, those parts were written before 1JS emerged and the consensus around 1JS seems to be try to gracefully extend the current ES5 semantics to encompass such new feature without early error restrictions. We have discussed here doing what SpiderMonkey already does: the strict-mode ban on duplicate parameter names when you opt into destructuring. This is entirely consistent with 1JS, and it makes the language better for users and implementors, from what I've seen. Also, at the last meeting there was some significant push back about the load-time costs (startup latency) of early error detection. That's an issue for sure but we talked last week about less-than-early errors for some things. OTOH even a stripped down parser or reader must cope with some name binding checks per ES5 strict mode (as well as recognizing use strict;). That ship sailed. Same goes for duplicate property names in object literals in strict mode. The real objection was to full name def/use analysis, which this is not. Duplicate formals are pretty easy to detect and you have to throw an early error for any such given a use strict; (later!) in the same function. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: repeated parameter names and default values
On Sep 27, 2012, at 9:45 AM, David Bruant wrote:
...
Also, is there really a value in being able reuse a previous argument to
define the value of another argument?
The idea of for the second argument, use its value unless it's
undefined in which case, reuse the value of the first argument smells
like poorly designed code or API, but I'm curious if some can show a
case where it's legitimate.
David
function doSomethingToAnArray(a, limit=a.length) {
...
}
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: repeated parameter names and default values
On Sep 27, 2012, at 10:09 AM, Jason Orendorff wrote:
On Thu, Sep 27, 2012 at 11:19 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
function f(a, b=a, a=3, c=a) {
return a+ +b+ +c
}
console.log(f(1));
Based upon the conclusions about argument binding at the recent TC39 meeting
this will display:
3 1 3
Not having been at the meeting, I had a little trouble coming up with
a desugaring where this worked. Is this the idea?
function f(a, b, a, c) {
var %args = a copy of arguments;
a = %args[0];
b = %args[1] === void 0 ? a : %args[1];
a = %args[2] === void 0 ? 3 : %args[2];
c = %args[3] === void 0 ? a : %args[3];
return a+ +b+ +c;
}
Yes, essentially that plus presumably appropriate length checks on %args.
Also, I assume by arguments you mean the actual passed argument vector rather
than the arguments object.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: repeated parameter names and default values
On Sep 27, 2012, at 10:26 AM, Brendan Eich wrote: Allen Wirfs-Brock wrote: My original intent was to apply such rules and the current spec. draft actually has some of these restrictions. However, those parts were written before 1JS emerged and the consensus around 1JS seems to be try to gracefully extend the current ES5 semantics to encompass such new feature without early error restrictions. We have discussed here doing what SpiderMonkey already does: the strict-mode ban on duplicate parameter names when you opt into destructuring. This is entirely consistent with 1JS, and it makes the language better for users and implementors, from what I've seen. Also, at the last meeting there was some significant push back about the load-time costs (startup latency) of early error detection. That's an issue for sure but we talked last week about less-than-early errors for some things. OTOH even a stripped down parser or reader must cope with some name binding checks per ES5 strict mode (as well as recognizing use strict;). That ship sailed. Same goes for duplicate property names in object literals in strict mode. The real objection was to full name def/use analysis, which this is not. Duplicate formals are pretty easy to detect and you have to throw an early error for any such given a use strict; (later!) in the same function. So the purpose my original posting is achieved. I'm all for statically disallowing many of these stupid cases and I think it is fine to do the checks at first call rather than load-time (a off-line static linter could be more aggressive in reporting such errors). Since the consensus here seems to be the same, I'll take that approach as I update the spec. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: repeated parameter names and default values
On 2012-09-27 9:19 AM, Allen Wirfs-Brock wrote:
Consider
function f(a, b= a=3, c=a) {
return a+ +b+ +c
}
console.log(f(1));
Based upon the conclusions about argument binding at the recent TC39 meeting
this will display:
3 1 3
Any disagreement of this?
A constantly recurring question in this effort is Do we want it to be
consistent, or do we want it to be better?
I am always in favor of better. So parameter names should not be repeatable.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
a new ES6 spec. draft dis available
As usual, at http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts Changes include: Significant reworking of the use of cover grammars for unambiguously defining assignment restructuring patterns and for arrow function formal parameters. Renaming of Quasis to Template Strings Incorporated Class definition semantic decisions from July TC39 meeting Make concise methods enumerable, as per Sept. TC39 meeting. A first cut at making Object.prototype.toString extensible via a Unique Symbol extension point. Started to rough in binary data and typed arrays into Section 15. At this point it is mostly just material copied directly from wiki proposals. Lots of integration and detailed specification work remains. Fully specified Map builtin as 15.14. This also serves as model for how other new built-in collections will be specified. Roughed in section 15 places holders for Set, Weakmap, Proxy, and the Reflect module. Feedback on overall organization of this material is welcome. Many fixes of both unreported and reported bugs, including:256, 464-468,470-479, 482-484,486,488,490-497,499,502,506,506-510,514, 515, 520, 521, 527, 529-537,539-559, 561-564, 566-569, 571, 572, 576, 579-587, 589, 592, 597-599, 601-609,612, 614-616, 618, 620-623, 626, 628-630, 633,635,639-644,650,653 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: repeated parameter names and default values
Allen Wirfs-Brock wrote: On Sep 27, 2012, at 10:26 AM, Brendan Eich wrote: Also, at the last meeting there was some significant push back about the load-time costs (startup latency) of early error detection. That's an issue for sure but we talked last week about less-than-early errors for some things. OTOH even a stripped down parser or reader must cope with some name binding checks per ES5 strict mode (as well as recognizing use strict;). That ship sailed. Same goes for duplicate property names in object literals in strict mode. The real objection was to full name def/use analysis, which this is not. Duplicate formals are pretty easy to detect and you have to throw an early error for any such given a use strict; (later!) in the same function. So the purpose my original posting is achieved. Ok, but... I'm all for statically disallowing many of these stupid cases and I think it is fine to do the checks at first call rather than load-time (a off-line static linter could be more aggressive in reporting such errors). No. As a matter using accurate language, that's not statically. More, you didn't respond to my use strict; point. Are you going to change whether duplicate parameters with use strict; in the function prologue throw an early error, or not? Since the consensus here seems to be the same, I'll take that approach as I update the spec. We have not discussed error-on-first-call in this thread at all! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: a new ES6 spec. draft dis available
Great! ES6 rev10 draft is very interesting, so I'm now reading this changes... And I've found typo in draft section 11.1.10, 11.1 StaticSemantics, , `IsValidSimpleAssignmentTarge` should be `IsValidSimpleAssignmentTarget` Regards, Yusuke Suzuki On Fri, Sep 28, 2012 at 5:15 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: As usual, at http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts Changes include: - Significant reworking of the use of cover grammars for unambiguously defining assignment restructuring patterns and for arrow function formal parameters. - Renaming of Quasis to Template Strings - Incorporated Class definition semantic decisions from July TC39 meeting - Make concise methods enumerable, as per Sept. TC39 meeting. - A first cut at making Object.prototype.toString extensible via a Unique Symbol extension point. - Started to rough in binary data and typed arrays into Section 15. At this point it is mostly just material copied directly from wiki proposals. Lots of integration and detailed specification work remains. - Fully specified Map builtin as 15.14. This also serves as model for how other new built-in collections will be specified. - Roughed in section 15 places holders for Set, Weakmap, Proxy, and the Reflect module. Feedback on overall organization of this material is welcome. - Many fixes of both unreported and reported bugs, including:256, 464-468,470-479, 482-484,486,488,490-497,499,502,506,506-510,514, 515, 520, 521, 527, 529-537,539-559, 561-564, 566-569, 571, 572, 576, 579-587, 589, 592, 597-599, 601-609,612, 614-616, 618, 620-623, 626, 628-630, 633,635,639-644,650,653 ___ 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: a new ES6 spec. draft dis available
Allen Wirfs-Brock wrote: As usual, at http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts Changes include: * Make concise methods enumerable, as per Sept. TC39 meeting. No! Why? Is there any meeting notes with it? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: a new ES6 spec. draft dis available
On Thu, Sep 27, 2012 at 3:12 PM, Herby Vojčík he...@mailbox.sk wrote: Allen Wirfs-Brock wrote: As usual, at http://wiki.ecmascript.org/**doku.php?id=harmony:**specification_draftshttp://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts Changes include: * Make concise methods enumerable, as per Sept. TC39 meeting. No! Why? Is there any meeting notes with it? I'm waiting for some final reviews from members of the group, once those are complete I will publish the meeting notes. Rick __**_ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: a new ES6 spec. draft dis available
And I've found typo in Map implementation. 15.14.1.1 MapInitialization, step 6, `internal method` should be `internal property` Regards, Yusuke Suzuki On Fri, Sep 28, 2012 at 5:15 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: As usual, at http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts Changes include: - Significant reworking of the use of cover grammars for unambiguously defining assignment restructuring patterns and for arrow function formal parameters. - Renaming of Quasis to Template Strings - Incorporated Class definition semantic decisions from July TC39 meeting - Make concise methods enumerable, as per Sept. TC39 meeting. - A first cut at making Object.prototype.toString extensible via a Unique Symbol extension point. - Started to rough in binary data and typed arrays into Section 15. At this point it is mostly just material copied directly from wiki proposals. Lots of integration and detailed specification work remains. - Fully specified Map builtin as 15.14. This also serves as model for how other new built-in collections will be specified. - Roughed in section 15 places holders for Set, Weakmap, Proxy, and the Reflect module. Feedback on overall organization of this material is welcome. - Many fixes of both unreported and reported bugs, including:256, 464-468,470-479, 482-484,486,488,490-497,499,502,506,506-510,514, 515, 520, 521, 527, 529-537,539-559, 561-564, 566-569, 571, 572, 576, 579-587, 589, 592, 597-599, 601-609,612, 614-616, 618, 620-623, 626, 628-630, 633,635,639-644,650,653 ___ 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: a new ES6 spec. draft dis available
On Thu, Sep 27, 2012 at 3:47 PM, Yusuke Suzuki utatane@gmail.comwrote: And I've found typo in Map implementation. 15.14.1.1 MapInitialization, step 6, `internal method` should be `internal property` Can you file a bug for this https://bugs.ecmascript.org/process_bug.cgi Rick Regards, Yusuke Suzuki On Fri, Sep 28, 2012 at 5:15 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: As usual, at http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts Changes include: - Significant reworking of the use of cover grammars for unambiguously defining assignment restructuring patterns and for arrow function formal parameters. - Renaming of Quasis to Template Strings - Incorporated Class definition semantic decisions from July TC39 meeting - Make concise methods enumerable, as per Sept. TC39 meeting. - A first cut at making Object.prototype.toString extensible via a Unique Symbol extension point. - Started to rough in binary data and typed arrays into Section 15. At this point it is mostly just material copied directly from wiki proposals. Lots of integration and detailed specification work remains. - Fully specified Map builtin as 15.14. This also serves as model for how other new built-in collections will be specified. - Roughed in section 15 places holders for Set, Weakmap, Proxy, and the Reflect module. Feedback on overall organization of this material is welcome. - Many fixes of both unreported and reported bugs, including:256, 464-468,470-479, 482-484,486,488,490-497,499,502,506,506-510,514, 515, 520, 521, 527, 529-537,539-559, 561-564, 566-569, 571, 572, 576, 579-587, 589, 592, 597-599, 601-609,612, 614-616, 618, 620-623, 626, 628-630, 633,635,639-644,650,653 ___ 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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: repeated parameter names and default values
On 9/27/12 at 9:41, al...@wirfs-brock.com (Allen Wirfs-Brock) wrote: A big part of of my job is specifying what stupid code does. This job is a vital job if you want a completely specified language. (BTW - I know of no completely specified languages, or other computer system components for that matter, but the closer the specification comes to being complete, the better). Congratulations to Allen on the job he is doing for Javascript. Cheers - Bill --- Bill Frantz| Truth and love must prevail | Periwinkle (408)356-8506 | over lies and hate. | 16345 Englewood Ave www.pwpconsult.com | - Vaclav Havel | Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: a new ES6 spec. draft dis available
Thanks, I've filed them. https://bugs.ecmascript.org/show_bug.cgi?id=664 https://bugs.ecmascript.org/show_bug.cgi?id=665 https://bugs.ecmascript.org/show_bug.cgi?id=666 Regards, Yusuke Suzuki On Fri, Sep 28, 2012 at 10:05 AM, Rick Waldron waldron.r...@gmail.comwrote: On Thu, Sep 27, 2012 at 3:47 PM, Yusuke Suzuki utatane@gmail.comwrote: And I've found typo in Map implementation. 15.14.1.1 MapInitialization, step 6, `internal method` should be `internal property` Can you file a bug for this https://bugs.ecmascript.org/process_bug.cgi Rick Regards, Yusuke Suzuki On Fri, Sep 28, 2012 at 5:15 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: As usual, at http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts Changes include: - Significant reworking of the use of cover grammars for unambiguously defining assignment restructuring patterns and for arrow function formal parameters. - Renaming of Quasis to Template Strings - Incorporated Class definition semantic decisions from July TC39 meeting - Make concise methods enumerable, as per Sept. TC39 meeting. - A first cut at making Object.prototype.toString extensible via a Unique Symbol extension point. - Started to rough in binary data and typed arrays into Section 15. At this point it is mostly just material copied directly from wiki proposals. Lots of integration and detailed specification work remains. - Fully specified Map builtin as 15.14. This also serves as model for how other new built-in collections will be specified. - Roughed in section 15 places holders for Set, Weakmap, Proxy, and the Reflect module. Feedback on overall organization of this material is welcome. - Many fixes of both unreported and reported bugs, including:256, 464-468,470-479, 482-484,486,488,490-497,499,502,506,506-510,514, 515, 520, 521, 527, 529-537,539-559, 561-564, 566-569, 571, 572, 576, 579-587, 589, 592, 597-599, 601-609,612, 614-616, 618, 620-623, 626, 628-630, 633,635,639-644,650,653 ___ 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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Early error vs. error on first call to function vs. runtime error
Brendan Eich wrote:
We have not discussed error-on-first-call in this thread at all!
This needs a separate thread. The idea from last week's TC39 meeting was
to have not only
* Early error, thrown before any code in the Program (grammar goal
symbol) containing the error, required by specific language in Clause 16.
* Runtime error, all the other kinds.
and now
* Error on first call to a function, where the function contains what
would be an early error but for the supposed cost of early error analysis.
The last case is really just a runtime error: a function with what
should be a static error becomes a booby trap: if your tests happen to
miss calling it, you'll feel ok, but a user who tickles the uncovered
path will get a runtime error.
TC39 heard from some implementors who wanted to avoid more early error
requirements in ES6, or at least any that require analysis, e.g.
reaching definitions.
That's fair as input to the committee, but implementation concerns are
not the only ones we weigh. And we were far from agreed on adding the
Error on first call category.
The example you imply here would be
function f(a, b = c, a = d) {
}
and the duplicate formal a would be illegal because of the novel
default-parameter syntax.
Making f into a proximity-fused bomb does not see either good or
necessary. The analysis requires to notice duplicate formals is trivial,
and as I keep pointing out, ES5 already requires it:
function g(a, a) {
use strict;
}
This must be an early error per ES5 clause 16.
Given the ES5-strict sunk cost, there's no added implementation tax
beyond the logic conjoining duplicate detection with novel-syntax
detection, which is trivial.
It'd be good to hear from Luke on this.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Early error vs. error on first call to function vs. runtime error
As a user, not implementer, I really want early errors. Perf costs of startup
are negligible especially long-term. By the time ES6 is in browsers computers
and phones should be faster by enough of a factor to mitigate any costs,
whereas omitting early errors hurts developers indefinitely into the future.
On Sep 28, 2012, at 4:02, Brendan Eich bren...@mozilla.org wrote:
Brendan Eich wrote:
We have not discussed error-on-first-call in this thread at all!
This needs a separate thread. The idea from last week's TC39 meeting was to
have not only
* Early error, thrown before any code in the Program (grammar goal symbol)
containing the error, required by specific language in Clause 16.
* Runtime error, all the other kinds.
and now
* Error on first call to a function, where the function contains what would
be an early error but for the supposed cost of early error analysis.
The last case is really just a runtime error: a function with what should be
a static error becomes a booby trap: if your tests happen to miss calling it,
you'll feel ok, but a user who tickles the uncovered path will get a runtime
error.
TC39 heard from some implementors who wanted to avoid more early error
requirements in ES6, or at least any that require analysis, e.g. reaching
definitions.
That's fair as input to the committee, but implementation concerns are not
the only ones we weigh. And we were far from agreed on adding the Error on
first call category.
The example you imply here would be
function f(a, b = c, a = d) {
}
and the duplicate formal a would be illegal because of the novel
default-parameter syntax.
Making f into a proximity-fused bomb does not see either good or necessary.
The analysis requires to notice duplicate formals is trivial, and as I keep
pointing out, ES5 already requires it:
function g(a, a) {
use strict;
}
This must be an early error per ES5 clause 16.
Given the ES5-strict sunk cost, there's no added implementation tax beyond
the logic conjoining duplicate detection with novel-syntax detection, which
is trivial.
It'd be good to hear from Luke on this.
/be
___
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: Early error vs. error on first call to function vs. runtime error
Domenic Denicola wrote:
As a user, not implementer, I really want early errors. Perf costs of startup
are negligible especially long-term. By the time ES6 is in browsers computers
and phones should be faster by enough of a factor to mitigate any costs,
whereas omitting early errors hurts developers indefinitely into the future.
Totally agree!
Others on TC39 made this point too. We're not near consensus, unfortunately.
/be
On Sep 28, 2012, at 4:02, Brendan Eichbren...@mozilla.org wrote:
Brendan Eich wrote:
We have not discussed error-on-first-call in this thread at all!
This needs a separate thread. The idea from last week's TC39 meeting was to
have not only
* Early error, thrown before any code in the Program (grammar goal symbol)
containing the error, required by specific language in Clause 16.
* Runtime error, all the other kinds.
and now
* Error on first call to a function, where the function contains what would be
an early error but for the supposed cost of early error analysis.
The last case is really just a runtime error: a function with what should be a
static error becomes a booby trap: if your tests happen to miss calling it,
you'll feel ok, but a user who tickles the uncovered path will get a runtime
error.
TC39 heard from some implementors who wanted to avoid more early error
requirements in ES6, or at least any that require analysis, e.g. reaching
definitions.
That's fair as input to the committee, but implementation concerns are not the only ones
we weigh. And we were far from agreed on adding the Error on first call
category.
The example you imply here would be
function f(a, b = c, a = d) {
}
and the duplicate formal a would be illegal because of the novel
default-parameter syntax.
Making f into a proximity-fused bomb does not see either good or necessary. The
analysis requires to notice duplicate formals is trivial, and as I keep
pointing out, ES5 already requires it:
function g(a, a) {
use strict;
}
This must be an early error per ES5 clause 16.
Given the ES5-strict sunk cost, there's no added implementation tax beyond the
logic conjoining duplicate detection with novel-syntax detection, which is
trivial.
It'd be good to hear from Luke on this.
/be
___
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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: a new ES6 spec. draft dis available
B.3.1, “The __proto__ pseudo property” will eventually be moved out of the annex, right? If I may: I have two questions about this section. 1. Quote: “Manipulations of this property as tracked by the Boolean valued primordial internal variable UnderscoreProtoEnabled.” What is a primordial internal variable? That term does not appear anywhere else in the spec. 2. Quote: “The default initial value of UnderscoreProtoEnabled is true only if this property is initially present on the primordial Object prototype object.” I would have guessed that the variable being true also depends on whether or not Object.prototype is in the prototype chain. Thanks! Axel -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Early error vs. error on first call to function vs. runtime error
I'm generally against error on first call -- in the general case if you're able
to determine a function should fail on first execution you can determine that
it could fail during parsing and semantic analysis.
--Oliver
On Sep 27, 2012, at 9:01 PM, Brendan Eich bren...@mozilla.org wrote:
Domenic Denicola wrote:
As a user, not implementer, I really want early errors. Perf costs of
startup are negligible especially long-term. By the time ES6 is in browsers
computers and phones should be faster by enough of a factor to mitigate any
costs, whereas omitting early errors hurts developers indefinitely into the
future.
Totally agree!
Others on TC39 made this point too. We're not near consensus, unfortunately.
/be
On Sep 28, 2012, at 4:02, Brendan Eichbren...@mozilla.org wrote:
Brendan Eich wrote:
We have not discussed error-on-first-call in this thread at all!
This needs a separate thread. The idea from last week's TC39 meeting was to
have not only
* Early error, thrown before any code in the Program (grammar goal symbol)
containing the error, required by specific language in Clause 16.
* Runtime error, all the other kinds.
and now
* Error on first call to a function, where the function contains what would
be an early error but for the supposed cost of early error analysis.
The last case is really just a runtime error: a function with what should
be a static error becomes a booby trap: if your tests happen to miss
calling it, you'll feel ok, but a user who tickles the uncovered path will
get a runtime error.
TC39 heard from some implementors who wanted to avoid more early error
requirements in ES6, or at least any that require analysis, e.g. reaching
definitions.
That's fair as input to the committee, but implementation concerns are not
the only ones we weigh. And we were far from agreed on adding the Error on
first call category.
The example you imply here would be
function f(a, b = c, a = d) {
}
and the duplicate formal a would be illegal because of the novel
default-parameter syntax.
Making f into a proximity-fused bomb does not see either good or necessary.
The analysis requires to notice duplicate formals is trivial, and as I keep
pointing out, ES5 already requires it:
function g(a, a) {
use strict;
}
This must be an early error per ES5 clause 16.
Given the ES5-strict sunk cost, there's no added implementation tax beyond
the logic conjoining duplicate detection with novel-syntax detection, which
is trivial.
It'd be good to hear from Luke on this.
/be
___
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
___
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: Early error vs. error on first call to function vs. runtime error
Oliver Hunt wrote:
I'm generally against error on first call -- in the general case if you're able
to determine a function should fail on first execution you can determine that
it could fail during parsing and semantic analysis.
Ok, to play fair I should ask how you feel about any analysis that is
not cheap enough to do during a parse or lex/read pass required to
lazily compile functions on first call. What about binding analysis,
recognizing every statically resolvable use of a definition, possibly
making free variable uses early errors when inside module {...}?
/be
--Oliver
On Sep 27, 2012, at 9:01 PM, Brendan Eichbren...@mozilla.org wrote:
Domenic Denicola wrote:
As a user, not implementer, I really want early errors. Perf costs of startup
are negligible especially long-term. By the time ES6 is in browsers computers
and phones should be faster by enough of a factor to mitigate any costs,
whereas omitting early errors hurts developers indefinitely into the future.
Totally agree!
Others on TC39 made this point too. We're not near consensus, unfortunately.
/be
On Sep 28, 2012, at 4:02, Brendan Eichbren...@mozilla.org wrote:
Brendan Eich wrote:
We have not discussed error-on-first-call in this thread at all!
This needs a separate thread. The idea from last week's TC39 meeting was to
have not only
* Early error, thrown before any code in the Program (grammar goal symbol)
containing the error, required by specific language in Clause 16.
* Runtime error, all the other kinds.
and now
* Error on first call to a function, where the function contains what would be
an early error but for the supposed cost of early error analysis.
The last case is really just a runtime error: a function with what should be a
static error becomes a booby trap: if your tests happen to miss calling it,
you'll feel ok, but a user who tickles the uncovered path will get a runtime
error.
TC39 heard from some implementors who wanted to avoid more early error
requirements in ES6, or at least any that require analysis, e.g. reaching
definitions.
That's fair as input to the committee, but implementation concerns are not the only ones
we weigh. And we were far from agreed on adding the Error on first call
category.
The example you imply here would be
function f(a, b = c, a = d) {
}
and the duplicate formal a would be illegal because of the novel
default-parameter syntax.
Making f into a proximity-fused bomb does not see either good or necessary. The
analysis requires to notice duplicate formals is trivial, and as I keep
pointing out, ES5 already requires it:
function g(a, a) {
use strict;
}
This must be an early error per ES5 clause 16.
Given the ES5-strict sunk cost, there's no added implementation tax beyond the
logic conjoining duplicate detection with novel-syntax detection, which is
trivial.
It'd be good to hear from Luke on this.
/be
___
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
___
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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
