RE: Look Ma, no this (was: ECMAScript Harmony)

2008-08-19 Thread Allen Wirfs-Brock
I thought it was Peter Deutsch who originally said you can cheat if you don't get caught. regarding Smalltalk implementations -Original Message- From: [EMAIL PROTECTED] [mailto:es-discuss- [EMAIL PROTECTED] On Behalf Of Mark S. Miller Sent: Tuesday, August 19, 2008 6:03 PM To:

RE: Next meeting?

2008-09-07 Thread Allen Wirfs-Brock
Yes, the wiki is basically up to date. You should have also gotten a venue announcement via the TC-39 mailing list. The plan is to spend as much as necessary of the first and second day resolve outstanding ES3.1 issue and the reminder of the meeting on emerging Harmony ideas. Allen

Matching/Kim Bruce research pointers

2008-09-26 Thread Allen Wirfs-Brock
At the TC-39 meeting I suggested that Kim Bruce's research in object-oriented typing is something that some people might want to look at as they think about the role of type annotations in Harmony. Here are some pointers to Bruce's work: http://www.cs.williams.edu/~kim/research.html His book

RE: Proposed change to typeof

2008-11-06 Thread Allen Wirfs-Brock
Here is the end-game plan that I envision taking into account my perception of the current state of the draft: 1) Latter today, a review draft for the Kona meeting will be published. This draft is intended to be technically complete but does internally identify various unresolved technical

RE: Draft of Function.prototype.bind.

2008-11-06 Thread Allen Wirfs-Brock
Note that appendices C, D, and E are not particularly complete or up to date. This is something we are going to try to work on between now and Kona as I believe that these summaries are very important to understanding the overall impact of ES3.1 Allen -Original Message- From:

RE: Draft of Function.prototype.bind.

2008-11-06 Thread Allen Wirfs-Brock
-Original Message- From: [EMAIL PROTECTED] [mailto:es3.x-discuss- [EMAIL PROTECTED] On Behalf Of Brendan Eich Sent: Thursday, November 06, 2008 8:05 PM ... TC39 has generally avoided adding new globals; JSON is it for ES3.1 (AFAIK), and since Murphy was an optimist, it is breaking

RE: Draft of Function.prototype.bind.

2008-11-07 Thread Allen Wirfs-Brock
/[[DefaultValue]]/hint mechanisms of the specification. -Original Message- From: Brendan Eich [mailto:[EMAIL PROTECTED] Sent: Friday, November 07, 2008 1:06 AM To: Allen Wirfs-Brock Cc: David-Sarah Hopwood; [EMAIL PROTECTED]; es- [EMAIL PROTECTED] Subject: Re: Draft

Unresolved 3.1 issue: statements and substatements

2008-11-09 Thread Allen Wirfs-Brock
The ES3 specification has a single grammar production Statement that specifies what can occur in nested statement contexts such as if statement then and else clauses. This allows for some strange looking but valid code such as: If (foo) var bar = baz; else var bar = bam; for (var i=0;

RE: Issues relating to 9.11 The SameValue Algorthm

2008-11-13 Thread Allen Wirfs-Brock
To: Allen Wirfs-Brock Cc: [EMAIL PROTECTED]; es-discuss@mozilla.org Subject: Re: Issues relating to 9.11 The SameValue Algorthm On Thu, Nov 13, 2008 at 10:31 AM, Allen Wirfs-Brock [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote: OK, I now see the difference between SameValue and StrictEquality

RE: === again (sorry)

2008-11-13 Thread Allen Wirfs-Brock
Now that this is pointed out the case that bothers me is code that looks something like this: switch (num) { case NaN: alert(NaN); case +Infinity: case -Infinity: alert(Infinity); default: alert(a fine old number); } The intent of the code is obvious and yet the NaN case

RE: === again (sorry)

2008-11-13 Thread Allen Wirfs-Brock
Ugh, I guess I left out a couple breaks... -Original Message- From: [EMAIL PROTECTED] [mailto:es-discuss- [EMAIL PROTECTED] On Behalf Of Allen Wirfs-Brock Sent: Thursday, November 13, 2008 6:00 PM To: Igor Bukanov; Waldemar Horwat Cc: Mark S. Miller; es-discuss Subject: RE: === again

RE: Kona [[Getter]] and [[Setter]] descriptions

2008-11-16 Thread Allen Wirfs-Brock
-Original Message- From: [EMAIL PROTECTED] [mailto:es-discuss- [EMAIL PROTECTED] On Behalf Of Peter Michaux Sent: Saturday, November 15, 2008 10:47 PM To: es-discuss@mozilla.org Subject: Kona [[Getter]] and [[Setter]] descriptions From section 8.6.1 ... Would the following be sufficient?

RE: Kona [[Configurable]]

2008-11-16 Thread Allen Wirfs-Brock
In addition to David-Sarah's points we hoped that repurposing the DontDelete attribute as [[Configurable]] would ease implementation level transition from ES3 to ES3.1. Assuming a implementation already has single bit encodings to represent DontDelete, DontEnum, and ReadOnly is may be less

RE: Kona [[Getter]] and [[Setter]] descriptions

2008-11-16 Thread Allen Wirfs-Brock
distinguishing the informative from the normative. Allen -Original Message- From: Peter Michaux [mailto:[EMAIL PROTECTED] Sent: Sunday, November 16, 2008 10:36 AM To: Allen Wirfs-Brock Cc: es-discuss@mozilla.org Subject: Re: Kona [[Getter]] and [[Setter]] descriptions On Sun, Nov 16, 2008

RE: Kona [[Getter]] and [[Setter]] descriptions

2008-11-16 Thread Allen Wirfs-Brock
OK, I like those definitions. Even though I just changed it I would now go back to calling them methods rather than functions (because this is bound when the functions are invoked). Also we lost the is before read in the [[Getter]] definition. So, the final form would be: [[Getter]] A

RE: Kona [[Getter]] and [[Setter]] descriptions

2008-11-16 Thread Allen Wirfs-Brock
@mozilla.org; [EMAIL PROTECTED] Subject: Re: Kona [[Getter]] and [[Setter]] descriptions Allen Wirfs-Brock wrote: OK, I like those definitions. Even though I just changed it I would now go back to calling them methods rather than functions (because this is bound when the functions are invoked). Also

RE: Allen's lambda syntax proposal

2008-12-01 Thread Allen Wirfs-Brock
Just to clarify some speculation, the syntax I proposed ({||}) was solely inspired by Smalltalk and tempered by the parsing realities of a C-like syntax. Any similarities to Ruby constructs are probably examples of parallel evolution under similar environmental pressures. I suspect that

RE: RE: Allen's lambda syntax proposal

2008-12-01 Thread Allen Wirfs-Brock
-Original Message- From: [EMAIL PROTECTED] [mailto:es-discuss- [EMAIL PROTECTED] On Behalf Of Douglas Crockford ... because you can think of the \ as being an abbreviation of function. \ name(a,b,c) {} Just don't start your function name with u. Exactly, that's why I didn't

RE: Allen's lambda syntax proposal

2008-12-01 Thread Allen Wirfs-Brock
Below -Original Message- From: Maciej Stachowiak [mailto:[EMAIL PROTECTED] Can you give an example? Since ECMAScript's built-in control structures already have special syntax, it's hard to make anything look *exactly* like them. Here's my best shot at an example. Let's pretend you have a

RE: Allen's lambda syntax proposal

2008-12-05 Thread Allen Wirfs-Brock
From: Brendan Eich [mailto:[EMAIL PROTECTED] The return hazard exists in Smalltalk too. What's different here that makes you choose differently? Of course, there are more choices than Tennent-to-the-max lambdas or-else classes-as-sugar. The difference is in the foundation language we are

RE: Bait taken: Arguments about arguments

2009-01-09 Thread Allen Wirfs-Brock
I created distinct Trac tickets for the separable issues being discussed here: Ticket #428 has been reopened and should be specifically about isArray and whether or not it return true for the arguments object http://bugs.ecmascript.org/ticket/428 Ticket #447 is about whether or not arguments

RE: Bait taken: Arguments about arguments

2009-01-15 Thread Allen Wirfs-Brock
At Tuesday's ES3.1 conference call we discussed the three major outstanding issues regarding the arguments object that had been discussed on this list and made decisions for incorporation into the Mountain View draft that was released earlier today. These decisions were: Ticket #428: what

Function apply and call (was RE: Bait taken: Arguments about arguments)

2009-01-15 Thread Allen Wirfs-Brock
I generally agree that it would be a good idea to specify apply (and call) pretty much as proposed below by David-Sarah. The major reason that it makes it explicit what happens for most currently unspecified edge cases such as a sparse argArray or argArray properties that are accessors. It

RE: Stale strict mode restrictions?

2009-01-15 Thread Allen Wirfs-Brock
Now, I'm scared as clearly remember deleting those sections from my copy yesterday. I need to do some digging to figure out whether it's the draft or my mind that is defective. allen From: es3.x-discuss-boun...@mozilla.org [mailto:es3.x-discuss-boun...@mozilla.org] On Behalf Of Mark S.

RE: Revisiting Decimal (generic algorithms)

2009-01-16 Thread Allen Wirfs-Brock
Returning to Brendan's original question... The problem I brought up at the Kona meeting was that the Decimal proposal did not consistently enable the writing of functions that implement generic numeric algorithms. By this I mean algorithms that can be applied to either Number or Decimal

Function.prototype.bind and [[Construct]]

2009-01-16 Thread Allen Wirfs-Brock
The Kona minutes state bind behavior: Should bind create only a call or both a call and a construct bound property? We decided to stick to last meeting's decision of creating both a call and a construct bound property. (If it were just call, then the argument for adding bind to the language at

[[Class]] and host objects

2009-02-06 Thread Allen Wirfs-Brock
At the Mountain view meeting we agreed to remove the host object exemption regarding [[Class]] so we could reliably use it discriminate types of objects. I'm trying to implement this in the specification, but what does it really mean? ES3 currently says: The value of the [[Class]] property

Is EvalError still needed?

2009-02-09 Thread Allen Wirfs-Brock
The Mountain View notes don't directly address this and I don't recall us discussing it specifically at the meeting but it seems that the formalization of direct and indirect evals and their scoping means that the ES3 permission for an implementation to essentially forbid indirect evals or the

RE: [[Class]] and host objects

2009-02-09 Thread Allen Wirfs-Brock
-Original Message- From: Waldemar Horwat [mailto:walde...@google.com] Sent: Monday, February 09, 2009 6:30 PM ... As you guys mentioned, the bigger question is what to do about multiple global objects. That's the issue in reality and we shouldn't add anything to the spec that would be

RE: [[Class]] and host objects

2009-02-10 Thread Allen Wirfs-Brock
Mark Miller said: We can get the effect of specifying such indistinguishability simply by specifying that host objects may have as their [[Class]] property Object, or any string not otherwise used by the spec as a [[Class]] value. I generally agree, but I have two what about's that actually

RE: Is EvalError still needed?

2009-02-10 Thread Allen Wirfs-Brock
obsolete. Indirect eval would seem to have no utility (at least for web applications) if it is an optional feature. Allen -Original Message- From: Waldemar Horwat [mailto:walde...@google.com] Sent: Tuesday, February 10, 2009 6:19 PM To: Allen Wirfs-Brock Cc: es-discuss Subject: Re

RE: Is EvalError still needed?

2009-02-10 Thread Allen Wirfs-Brock
editions.] -Original Message- From: Brendan Eich [mailto:bren...@mozilla.com] Sent: Tuesday, February 10, 2009 6:33 PM To: Allen Wirfs-Brock Cc: Waldemar Horwat; Chris Pine; es-discuss Subject: Re: Is EvalError still needed? Chris Pine answered this one recently: https://mail.mozilla.org

What strict mode eval declarations did we really ban?

2009-02-10 Thread Allen Wirfs-Brock
Waldemar's Mountain View notes said: - Agreed to disallow the use of eval as the name of a local variable, function parameter, etc. in strict mode. Did we really mean that only function scoped declarations are so restricted? What about var declarations in strict global code? What about

RE: [[Class]] and host objects

2009-02-11 Thread Allen Wirfs-Brock
...@gmail.com] Sent: Tuesday, February 10, 2009 10:12 PM To: Allen Wirfs-Brock Cc: Mark S. Miller; Brendan Eich; Mark Miller; es-discuss Subject: Re: [[Class]] and host objects On Feb 10, 2009, at 9:15 PM, Allen Wirfs-Brock wrote: Mark Miller: I like your #2 direction a lot. If it were feasible

assignment to eval in strict code

2009-02-12 Thread Allen Wirfs-Brock
Now that we have decided that all declarations of the identifier eval are banned from strict code a related question has come up from one of the implementers of our strict mode prototype implementation.Why does Es3.1 still allow assignment to the identifier eval within strict code? That

RE: ES1-3 eval-created function bindings can be used to destroy caller bindings

2009-02-13 Thread Allen Wirfs-Brock
ES3.1 changes the rules to use CreateMutableBinding when entering the eval execution context only if x is not already bound, and in any case then to call SetMutableBinding (10.2.1.2.3 in the feb09 draft). SetMutableBinding calls [[ThrowingPut]]. Strict mode adds value in its own way but let's

RE: Is EvalError still needed?

2009-02-13 Thread Allen Wirfs-Brock
I ending up using EvalError for the strict mode situations where we forbid declaration of eval. -Original Message- From: Waldemar Horwat [mailto:walde...@google.com] Sent: Thursday, February 12, 2009 4:58 PM To: Brendan Eich Cc: Mark S. Miller; Allen Wirfs-Brock; Chris Pine; es- disc

RE: assignment to eval in strict code

2009-02-13 Thread Allen Wirfs-Brock
The easiest place to ban it would be in PutValue as References now carry sufficient state to identify them as simple identifier bindings in strict mode. Allen From: Mark Miller [mailto:erig...@gmail.com] Sent: Thursday, February 12, 2009 5:24 PM To: Waldemar Horwat Cc: Allen Wirfs-Brock; es

RE: Improving ECMAScript as a compilation target

2009-02-13 Thread Allen Wirfs-Brock
I haven't digested the details of this thread. However, I did want to go on record as saying this is an area of interest to Microsoft and something we would like to put more effort into (in the TC-39 context) after we wrap-up ES3.1. Now back to trying to finish editing for the final draft

RE: Improving ECMAScript as a compilation target

2009-02-13 Thread Allen Wirfs-Brock
Brendan Eich wrote: ... JS is used by many more programmers, amateur and pro, than C. It has to have better human factors than C. That goes against being a good code generator target language. I totally agree with the first two sentences. I reserve judgment regarding the third. Allen

RE: Improving ECMAScript as a compilation target

2009-02-13 Thread Allen Wirfs-Brock
Can you get off the fence on adding goto? How about call/cc? For now, I only have problems, not solutions. However, I think it is debatable whether call/cc is more approachable to beginners (who admittedly don't write compilers) than goto. Call/cc is probably less of an attractive nuisance

RE: Can an Array have array indexed accessor properties and other curiosities??

2009-02-15 Thread Allen Wirfs-Brock
-Original Message- From: Brendan Eich [mailto:bren...@mozilla.com] Sent: Sunday, February 15, 2009 10:43 AM ... What happens, if the [[DefineOwnProperty]] is used to create an accessor property of an array instance whose name is an array index. I've thought of three possibilities:

RE: The global object in browsers

2009-02-17 Thread Allen Wirfs-Brock
Perhaps this would be a good initial W3C HTML WG/ECMA TC-39 joint work item if we can expeditiously get past the bureaucratic hurdles. The fact that there isn't an existing consensus behavior among the major browsers would seem to present an opportunity to step back a bit and take a new look

RE: assignment to eval in strict code

2009-02-18 Thread Allen Wirfs-Brock
-Original Message- From: Mark S. Miller [mailto:erig...@google.com] Sent: Thursday, February 12, 2009 4:58 PM Good. So does anyone object to ES3.1-strict imposing the same restrictions on the magic name arguments as we will on eval? In strict mode, arguments is already defined using an

RE: The global object in browsers

2009-02-19 Thread Allen Wirfs-Brock
-Original Message- From: es-discuss-boun...@mozilla.org [mailto:es-discuss- boun...@mozilla.org] On Behalf Of Maciej Stachowiak ... I think Ian discharged his obligation by notifying TC39 of the issue and starting this discussion. At this point, the important thing is to come up with a

parseInt and implicit octal constants

2009-02-20 Thread Allen Wirfs-Brock
15.1.2.2 says: When radix is 0 or undefined and the string's number begins with a 0 digit not followed by an x or X, then the implementation may, at its discretion, interpret the number either as being octal or as being decimal. Implementations are encouraged to interpret numbers in this case

RE: parseInt and implicit octal constants

2009-02-22 Thread Allen Wirfs-Brock
David-Sarah Hopwood wrote: Herman Venter wrote: I appreciate that this proposal does not try to go all the way on octal. I am not so sure this is a good thing or that it makes the proposal more likely to succeed. I wouldn't be opposed to removing octal entirely from the spec, but bearing in

RE: ES3.1 Draft: 23 Feb 2009 version available

2009-02-25 Thread Allen Wirfs-Brock
Thanks, got it. Turns out this bug is a carryover from the ES3 spec. Keep them coming... -Original Message- From: es-discuss-boun...@mozilla.org [mailto:es-discuss- boun...@mozilla.org] On Behalf Of Michael Haufe Sent: Tuesday, February 24, 2009 7:50 PM To: es-discuss@mozilla.org

RE: How do arguments objects print?

2009-02-28 Thread Allen Wirfs-Brock
Good, this thread caused me to identify another bug, step 4 of 10.5 (create the arguments Object) currently sets the [[Constructor]] (???) internal property to Object. It should be using [[DefineOwnProperty]] to set the constructor property. This is necessary because Array.prototype

name property for built-in functions??

2009-02-28 Thread Allen Wirfs-Brock
Because we have introduced a name property for function objects we have to specify what values the built-in functions in Section 15 each have for this property. Note that the value of this property is intended to be a descriptive name and is not necessarily a simple identifier. We have

Array.prototype algorithms and reified property attributes

2009-02-28 Thread Allen Wirfs-Brock
I just want to point out a set of changes that will be in this week's ES3.1 draft and see if there are any contrary thoughts about the changes. Many of the algorithms that define the Array.prototype functions make extensive use of [[Put]] and [[Delete]] to move around the properties of an Array

RE: name property for built-in functions??

2009-03-01 Thread Allen Wirfs-Brock
Brendan Eich wrote: (Is printString a VB-ism? ;-) Oops... It's a Smalltalk-ism ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

RE: name property for built-in functions??

2009-03-01 Thread Allen Wirfs-Brock
From: Brendan Eich [mailto:bren...@mozilla.com] What should (new Function).name or (equivalently) Function().name return? Precedent in some engines: js (new Function).name anonymous An anonymous function expression returns the empty string in some implementations: js (function(){}).name js

RE: name property for built-in functions??

2009-03-01 Thread Allen Wirfs-Brock
Unless others speak up, the path of least resistance is to use for both unnamed function expressions and new Function as that language is already in the ES3.1 spec. ___ Es-discuss mailing list Es-discuss@mozilla.org

Reviewing the March 2, 2009 ES3.1 Draft

2009-03-03 Thread Allen Wirfs-Brock
any problems you find to this list and/or me as soon as possible. I will maintain a frequently updated Errata document on the wiki at the above URL. Thanks for all of your contributions-Let's get this thing done! Allen Wirfs-Brock ___ Es-discuss

RE: name property for built-in functions??

2009-03-03 Thread Allen Wirfs-Brock
:-( -Original Message- From: Brendan Eich [mailto:bren...@mozilla.com] Sent: Tuesday, March 03, 2009 3:25 PM To: Maciej Stachowiak Cc: Allen Wirfs-Brock; es-discuss@mozilla.org Subject: Re: name property for built-in functions?? On Mar 3, 2009, at 2:39 PM, Maciej Stachowiak wrote: Surprising though

RE: name property for built-in functions??

2009-03-03 Thread Allen Wirfs-Brock
...@mozilla.org [mailto:es-discuss- boun...@mozilla.org] On Behalf Of Allen Wirfs-Brock Sent: Tuesday, March 03, 2009 6:25 PM To: Brendan Eich; Maciej Stachowiak Cc: es-discuss@mozilla.org Subject: RE: name property for built-in functions?? Strictly speaking, this issue seems to be more about

RE: name property for built-in functions??

2009-03-04 Thread Allen Wirfs-Brock
[mailto:erig...@google.com] Sent: Tuesday, March 03, 2009 8:02 PM To: Allen Wirfs-Brock Cc: Brendan Eich; Maciej Stachowiak; es-discuss@mozilla.org Subject: Re: name property for built-in functions?? I like most of what you just proposed, except that I find it surprising that a function's .name

RE: Case transformations in strings

2009-03-04 Thread Allen Wirfs-Brock
Any input from our other Unicode experts would be appreciated... Here's what I found (running on Windows Vista): IE, FF, Opera \u00DF.toUpperCase() returns \u00DF Safari, Chrome \u00DF.toUpperCase() returns SS It would be interesting if somebody could try the above for FF and Opera on a

RE: name property for built-in functions??

2009-03-04 Thread Allen Wirfs-Brock
04, 2009 1:17 PM To: Allen Wirfs-Brock Cc: Mark S. Miller; Maciej Stachowiak; es-discuss@mozilla.org Subject: Re: name property for built-in functions?? On Mar 4, 2009, at 9:49 AM, Allen Wirfs-Brock wrote: I'm not sure that there ever was a stated requirement that Function.prototype.name yield

RE: feedback on 2nd March draft

2009-03-05 Thread Allen Wirfs-Brock
get and set aren't reserved, they are only used contextually as keywords within object literals use also isn't reserved and is only recognized as a keyword within a string literal that forms a use strict directive, see 14.1 let and yield aren't reserved but the NOTE at the end of 7.5.3 warns

RE: JSON.stringify 15.12.3, Str algorithm 9a

2009-03-05 Thread Allen Wirfs-Brock
Thanks, Both Crock and I agree with you, so I'll add this to the Errata 9.a should be: a. If value is finite then return ToString(value). Allen -Original Message- From: es-discuss-boun...@mozilla.org [mailto:es-discuss- boun...@mozilla.org] On Behalf Of Robert Sayre Sent: Thursday,

RE: name property for built-in functions??

2009-03-05 Thread Allen Wirfs-Brock
A number of questions/comments below -Original Message- From: Brendan Eich Sent: Thursday, March 05, 2009 5:40 PM Subject: Re: name property for built-in functions?? On Mar 5, 2009, at 5:34 PM, Maciej Stachowiak wrote: The authors of Objective-J and the Capuccino framework have asked

RE: Case transformations in strings

2009-03-05 Thread Allen Wirfs-Brock
-Original Message- From: es-discuss-boun...@mozilla.org [mailto:es-discuss- boun...@mozilla.org] On Behalf Of James Graham ... A further question concerns characters with context-sensitive case mappings. Are implementations expected to apply the context-sensitive case transformation or act

RE: What is an Object Type(O)?

2009-03-07 Thread Allen Wirfs-Brock
From: Juriy Zaytsev [mailto:kan...@gmail.com] Sent: Saturday, March 07, 2009 11:32 AM ... My initial test tries to rule out exactly all of the ECMAScript language types except an Object one - Undefined, Null, Boolean, String and Number. I think of these types as of primitives, therefore

RE: name property for built-in functions??

2009-03-08 Thread Allen Wirfs-Brock
I have another concern about the potential interactions between the proposed name property and toString. Apparently, there is a known use case of eval'ing the result of toString'ing a function in order to create a new function. If we assign synthetic names such as get_foo or set_foo to

RE: name property for built-in functions??

2009-03-09 Thread Allen Wirfs-Brock
-Original Message- From: es-discuss-boun...@mozilla.org [mailto:es-discuss- boun...@mozilla.org] On Behalf Of David-Sarah Hopwood I don't see why this is an interaction between 'name' and 'toString'. Isn't this issue independent of whether 'name' is present? Yes, but it was the

arguments.callee and strict mode

2009-03-10 Thread Allen Wirfs-Brock
In reviewing the spec. I was reminded that arguments.callee is disabled within strict mode functions. Do you recall why you wanted to do this, other than general dislike of arguments. It occurs to me, that using arguments.callee is the only way to express recursion within a function created

RE: arguments.callee and strict mode

2009-03-10 Thread Allen Wirfs-Brock
-Original Message- From: Douglas Crockford [mailto:doug...@crockford.com] It is not the only way. You can write an annonymous function that returns a named, recursive function. So arguments.callee is not required for that unlikely case. Not exactly equivalent if you are using the function

FunctionDeclaration as Statement note

2009-03-13 Thread Allen Wirfs-Brock
In reviewing the ES3.1 draft, I found an incomplete note at the end of Section 12 that was intended to explain why ES3.1 does not extent the Statement production to include FunctionDeclaration. I have drafted a proposed final form of this note and would be interested in any feedback. NOTE

Errata for Sunnyvale draft

2009-03-13 Thread Allen Wirfs-Brock
For all of you who are madly proof reading the ES3.1 Sunnyvale draft (that's all of you, right??) I want to point out that I've just posted Revision 6 of its errata to http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft Allen

RE: ES3.1 questions and issues

2009-03-17 Thread Allen Wirfs-Brock
Some thoughts below -Original Message- From: es-discuss-boun...@mozilla.org [mailto:es-discuss- boun...@mozilla.org] On Behalf Of Mark S. Miller Sent: Tuesday, March 17, 2009 4:43 PM To: es3.x-disc...@mozilla.org x-discuss; es-discuss Subject: ES3.1 questions and issues Some ES3.1

RE: ES3.1 questions and issues

2009-03-17 Thread Allen Wirfs-Brock
You're correct about map. It had previously used [[ThrowingPut]] rather than [[DefineOwnProperty]]. Over specification of non-essential requirements is not necessarily beneficial. I'm reluctant to over spec. these algorithms for these error cases. As section 5.2 says an implementation may

RE: ES3.1 questions and issues

2009-03-18 Thread Allen Wirfs-Brock
-Original Message- From: Tobie Langel [mailto:tobie.lan...@gmail.com] ... Some of the challenges faced by the Prototype JavaScript Framework involve certain methods specified in ES 3.1 (notably the new Array.prototype methods) which were implemented in Prototype prior to their

RE: ES3.1 questions and issues

2009-03-18 Thread Allen Wirfs-Brock
-Original Message- From: Mark S. Miller [mailto:erig...@google.com] Sent: Wednesday, March 18, 2009 9:13 AM To: Allen Wirfs-Brock ... So, in attempting to reason about the security of Caja, ADsafe, WebSandbox, FBJS2, or Jacaranda, we must find some precise codification of your No rational

RE: ES3.1 questions and issues

2009-03-18 Thread Allen Wirfs-Brock
-Original Message- From: Mark S. Miller [mailto:erig...@google.com] Sent: Wednesday, March 18, 2009 10:27 AM ... See again the language I propose for sort. While leaving the choice of sorting algorithm unspecified, I place bounds on the range of side effects it may cause even under

RE: ES3.1 questions and issues

2009-03-18 Thread Allen Wirfs-Brock
through with this change. -Original Message- From: Mark S. Miller [mailto:erig...@google.com] Sent: Wednesday, March 18, 2009 12:36 PM To: Allen Wirfs-Brock Cc: es3.x-disc...@mozilla.org x-discuss; es-discuss Subject: Re: ES3.1 questions and issues Excellent! +1! That captures my concern

RE: ES3.1 questions and issues

2009-03-18 Thread Allen Wirfs-Brock
of a feature detection protocol used to decide whether or not to install framework provided versions of some such methods. Allen -Original Message- From: Brendan Eich [mailto:bren...@mozilla.com] Sent: Wednesday, March 18, 2009 9:22 PM To: Tobie Langel Cc: Allen Wirfs-Brock; Mark Miller; es-discuss

Updated Errata

2009-03-19 Thread Allen Wirfs-Brock
An updated Errata (Rev. 7) and a version of the March 2 ES3.1 draft that integrates the Errata are now available on the wiki: http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft ___ Es-discuss mailing list Es-discuss@mozilla.org

RE: 15.4.4.5 Array.prototype.join

2009-03-20 Thread Allen Wirfs-Brock
You're right, the specified algorithm (which I believe is just a restatement of the goto-based algorithm in the ES 3 spec) doesn't have any sort of recursion stopper while common implementations do. Do any implementers have any comments on what criteria is actually being applied? This

RE: 15.4.4.21 Array.prototype.reduce ( callbackfn [ , initialValue [ , thisArg ] ] )

2009-03-21 Thread Allen Wirfs-Brock
Adding to David-Sarah's comments, here is how I would expect a call that needs to supply a thisArg to be expressed: a.reduce(f.bind(thisArg),init) It almost makes me wonder if we should drop the thisArg from the standard for the other array extra functions and leave it as an implementation

Exactly where is a RegularExpressionLiteral allowed?

2009-03-23 Thread Allen Wirfs-Brock
Pratap came up with an issue in reviewing the ES3.1 draft that I don't have a good answer to: Sections 7 and 5.1.2 mention InputElementDiv and InputElementRegExp. 7 There are two goal symbols for the lexical grammar. The InputElementDiv symbol is used in those syntactic grammar contexts

RE: Exactly where is a RegularExpressionLiteral allowed?

2009-03-23 Thread Allen Wirfs-Brock
=/ was my typo, it's not in the specification. But see below: From: Brendan Eich [mailto:bren...@mozilla.com] Sent: Monday, March 23, 2009 11:57 AM ... If you make the /= correction, there is no ambiguity. 7.1 last paragraph: Note that contexts exist in the syntactic grammar where both a

RE: Exactly where is a RegularExpressionLiteral allowed?

2009-03-23 Thread Allen Wirfs-Brock
-Original Message- From: es-discuss-boun...@mozilla.org [mailto:es-discuss- boun...@mozilla.org] On Behalf Of Brendan Eich Sent: Monday, March 23, 2009 6:39 PM It should be Literal, not PrimaryExpression. There is no technical difference (since Literal is only used as one of the

RE: Exactly where is a RegularExpressionLiteral allowed?

2009-03-24 Thread Allen Wirfs-Brock
OK, let's try to wrap up this issues. In addition to adding RegularExpressionLiteral to Literal, do we also agree to delete the third paragraph of section 7 that says: Note that contexts exist in the syntactic grammar where both a division and a RegularExpressionLiteral are permitted by the

Ecma Press Release regarding ECMA-262, 5th Edition Candidate Specificaiton

2009-04-09 Thread Allen Wirfs-Brock
Ecma has published their press release announcing that the next version of the ECMAScript standard will be known as ECMA-262, Fifth Edition and that its final candidate draft has been completed and is available for public review and testing. See

RE: ecmascript 5 and the script tag

2009-04-17 Thread Allen Wirfs-Brock
Thanks, Brendan, for an excellent summary of these issues. The question of script versioning, going forward, is of considerable interest to Microsoft/IE so we agree it is something that needs to be discussed and address, probably in the context of TC-39. I just had a couple of things to add:

RE: ecmascript 5 and the script tag

2009-04-17 Thread Allen Wirfs-Brock
-Original Message- From: Brendan Eich [mailto:bren...@mozilla.com] IE8 does have a form of global object versioning. In IE8 the JSON object and associated toJSON methods, the methods Object.defineProperty and Object.getOwnPropertyDescriptor(they only supports DOM objects in IE8),

RE: ecmascript 5 and the script tag

2009-04-20 Thread Allen Wirfs-Brock
There currently isn't any such API and it is debatable whether or not one is actually needed. In most cases, strict mode will be explicitly specified in lexically enclosing code (ie, in the same source file) so the code hypothetically wanting to make this test should already know whether or

RE: Array.prototype.indexOf use of SameValue()

2009-04-28 Thread Allen Wirfs-Brock
The first step of SameValue is 1. If Type(x) is different from Type(y), return false. undefined, null, and number are 3 distinct types so SameValue(null,1) - false and SameValue(undefined,1) - false -Original Message- From: es-discuss-boun...@mozilla.org [mailto:es-discuss-

RE: Improving ECMAScript as a compilation target

2009-05-04 Thread Allen Wirfs-Brock
I also captured these on the wiki page: In the function defined for the example's invoke item the first argument to apply probably should be obj rather than peer. I would be inclined to specify an additional argument (probably the first) for each handler function that would be passed the this

RE: Improving ECMAScript as a compilation target

2009-05-04 Thread Allen Wirfs-Brock
-Original Message- From: Brendan Eich [mailto:bren...@mozilla.com] On May 4, 2009, at 6:20 PM, Allen Wirfs-Brock wrote: In the function defined for the example's invoke item the first argument to apply probably should be obj rather than peer. Possibly, but in the example peer[id] may

RE: Array methods applied to strings

2009-05-11 Thread Allen Wirfs-Brock
Agreed, this is a problem. Which compatibility appendix item did you think might apply? None of them were intended to cover this situation. Allen -Original Message- From: es-discuss-boun...@mozilla.org [mailto:es-discuss- boun...@mozilla.org] On Behalf Of James Graham Sent: Monday, May

RE: Array methods applied to strings

2009-05-11 Thread Allen Wirfs-Brock
The motivation for replacing [[Put]] and [Delete]] calls with throwing versions in the Array prototype functions was to provide proactive notification when these algorithms were applied to arrays (or other objects) where the existence of non-writable properties might result in violations of the

RE: Array methods applied to strings

2009-05-11 Thread Allen Wirfs-Brock
-Original Message- From: Erik Arvidsson [mailto:erik.arvids...@gmail.com] ... I think the right solution would be to use a non throwing [[Put]] for the Array methods for backwards compatibility. NodeList and Arguments are the common array like structures that people use the array generics

RE: Array lengthening methods applied to maximally long arrays

2009-05-13 Thread Allen Wirfs-Brock
Here's what I observed: Opera 9.63 - conforms to ES3/ES5 spec. Range error on a.push(1) after creating a non-array index property named 4294967295 and leaving length as 4294967295 Chrome 1.0.154.65 conforms to ES3/ES5 spec. Range error on a.push(1) after creating a non-array index property

RE: Array lengthening methods applied to maximally long arrays

2009-05-13 Thread Allen Wirfs-Brock
Obviously I meant push rather than pop in the second to last paragraph -Original Message- From: es-discuss-boun...@mozilla.org [mailto:es-discuss- boun...@mozilla.org] On Behalf Of Allen Wirfs-Brock Sent: Wednesday, May 13, 2009 8:19 AM To: James Graham; es-discuss@mozilla.org; es5-disc

RE: Array lengthening methods applied to maximally long arrays

2009-05-13 Thread Allen Wirfs-Brock
From: Brendan Eich It's totally an edge case, but if everyone agrees, it will probably get spec'ed at some point. For ES5, probably not -- up to Allen at this point. It's already spec'ed to throw in both ES3 and ES5. It's in Array instance's [[DefineOwnProperty]] in ES5 and [[Put]] for ES3.

RE: Array Like Interface

2009-05-15 Thread Allen Wirfs-Brock
The ES specification implicitly defines such an interface. It is essentially, the union of the requirements that an object must support if it is going to work correctly with the specified generic array methods. Those implicit requirements are fairly basic, but include the standard specified

RE: Array Like Interface

2009-05-18 Thread Allen Wirfs-Brock
-Original Message- From: Garrett Smith [mailto:dhtmlkitc...@gmail.com] Right. The problem is that that implied interface is not fulfilled in a compatible way IE. IE has list-like host objects which do not work with Array generics, even though those objects appear to support [[Get]] and

  1   2   3   4   5   6   7   8   9   10   >