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 questions and issues that some Googlers have asked me to >relay: > >* At the end of 7.8.5 is the sentence "If the call to new RegExp would >generate an error, the error must be reported while scanning the >program." Presumably, the intention of this sentence applies only to >syntax errors. For example, if the call to new RegExp would generate >an out of memory error, we should not imply that this must instead be >reported at scanning time.
It presumably means syntax error and any static semantic errors that can be detected by statically examining the regular expression text. (I'm not sure if there are, any of the latter). The above sentence should probably be restarted as ""If the call to new RegExp would generate any of the errors specified in 15.10.4.1, the errors must be reported while scanning the program." > >* There is general confusion about when "scanning" is, i.e., what >temporal distinction is being made here. When I tried to clarify, I >found I may be confused as well. Can an implementation postpone >scanning a top level function until it is called? Until after earlier >top-level definitions and/or statements in its Program have been >evaluated? > The "scanning" terminology is a carryover from previous editions. It think a reasonable interpretation of the intended meaning of "reported while scanning" is that all such errors for any particular ECMAScript /Program/ (section 14 meaning) must be reported before any code of that /Program/ is executed. I'm not sure where such a definition should go in the specification. >* What about logical impossibilities like "/$.^/"? May an >implementation reject this at scan time? Must it? If not, then what >about during construction at runtime? > Only if it is explicitly defined as an error somewhere in the spec. Of course, an implementation would be free to use any available mechanism to issue a non-fatal warning. >* I do not know that the verbal agreement (from the ES3.1 phone calls) >that I summarize below is adequately captured by the current draft >spec: > >If a host object provides its own internal [[GetOwnProperty]] method, >the mutability implies by the descriptors it returns must be an upper >bound on the possible mutations of the described property. For >example, if an accessor (getter/setter) property is described as a >data property where the getter may return different values over time, >then the [[Writable]] attribute must be true. If the attributes may >change over time or if the property might disappear, then the >[[Configurable]] attribute must be true. If [[Writable]] and >[[Configurable]] are both false and the property is described as a >data property, then the host is effectively promising that the gotten >value will be stable and may validly be cached. > >Is this guarantee adequately captured? Where? It isn't captured. Now that Mark as written the words I can add them to section 8.6.2 > >* Annex B lists some aspects of consensus JavaScript as implemented by >some major browsers but purposely omitted from the normative spec. >However, other aspects of consensus JavaScript are not listed in Annex >B. Should they be? >__defineGetter__, __defineSetter__, __proto__ >nested function definitions, const >non-strict arguments.caller, <function>.caller, <function>.arguments >And now that <function>.toString()'s behavior has reverted to >unspecified, do we want to suggest particular behavior in Annex B? > Annex B is a carryover from previous editions. It is my impression (Brendan?) the functions in Annex B are either ones that existed in Editions 1 and/or 2 but are not in Edition 3 or functions that were implemented in IE and Mozilla prior to initial standardization. Personally, I don't think we should be adding to this section except for items that are actually removed from an Edition of the specification. I don't think we have any for ES3.1 The things listed above either have better alternatives provided by ES3.1, are implemented by various implementation with irreconcilable differences (so which version would be describe?), do not have consensus regarding their semantics or impact on the existing language, or are hazards that we don't want to encourage. I think any of these concerns is enough to not include something. If we had agreement on that <function>.toString should do, we would put it into the spec, not the Annes. >* Array.prototype.sort was a particularly tricky thing to specify, >since we do not wish to specify which sorting algorithm an >implementation must use, even though the resulting differences are >observable by side-effecting comparefn, getters, and setters. Were we >to specify any normal sorting algorithm in our normal pseudo-code >algorithmic style, the sort() function itself would [[Get]] "length", >make some set of [[Get]]s, [[Put]]s, [[Delete]]s, on numerically named >properties between 0 and length-1, where values [[Put]] would only be >values obtained from previous [[Get]]s, and would make some set of >calls to comparefn, using only values obtained from previous [[Get]]s. >Each of these operations may behave badly in a number of ways, in >which case the specified sort routine will fail to sort. But the only >side effects sort would cause would be that brought about by calling >these other operations. If any of these operations throw, I would >expect sort() not to intercept it but to let it propagate, terminating >the sort(). > >Notice that I said all that without naming a specific sort algorithm. >Would it be reasonable to tighten the sort spec, including the sort >failure spec, in this way? In all other Array.prototype functions (and some other places) where similar possibilities exist, I have a situational appropriate variation of a sentence such as "The final state of O is unspecified if in the above algorithm any call to the [[ThrowingPut]] or [[Delete]] internal method of O throws an exception." I didn't add one for sort because I thought there were already enough caveats in the sort specification to cover it. Among other things, it says that sort behavior is implementation defined "If any property of this array whose property name is a nonnegative integer less than len is an accessor property." The exception propagation issue applies to any operation that might throw that is used in the specification of any section 15 function. I think, what is supported to happen is reasonably covered in the last paragraph of 5.2 > >IIUC, [[Delete]] is only included so that a sort algorithm can pack an >array with holes in it if it wishes. Is this behavior important? Could >we instead tighten the spec to add a requirement that the supposed >array be packed? What does sort() do on existing browsers on arrays >with holes? > Many of the other Array.prototype function also explicitly deal with holes in a well specified manner. While we might debate the utility of this, I do see any good reason of deprecate it at this time. >* For the identifiers we are already confident will become keywords as >of ES-Harmony -- "const" and "let", perhaps "yield" and "lambda" -- >would it make sense to make these keywords now in strict code? > > "The best laid plans of mice and men..." I'm not a big fan of this approach. Just look at how much mileage we've gotten out of the future reserved words :-) > > >-- > 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
