To FootThis page is <http://www.merlyn.demon.co.uk/js-262-5.htm>.
This page is an update of what was offered in Summer 2009 to TC39 as comment on the Final Draft of ECMA 262 5th Edition (try the Wayback Machine for that). After the 5th Edition is formally released, this should be revised for consideration by those interested in a 6th Edition. Material applying only to FD5 will be removed.
I have mainly studied the parts of the Documents for which I have some expertise, and merely looked through the rest.
Final Draft Standard ECMA-262
5th Edition / April 2009
(3.38 MB PDF)
includes :-
Not yet.
Or "Table of Contents" ??
Line "Annex B 218" is duplicated.
It seems to me that, in the chart of lexical White Space, Other category "Zs" Any other Unicode "space separator" <USP> may be too ambiguous. (For example, different browsers have different interpretations of which characters should be in the RegExps "White Space" set.)
One wonders why HexDigit is in this section, as it is not used until section 7.8.3.
Is there no undefined literal? Firefox and IE seem to have it. In source, the string 'undefined' appears to be on the same footing as the string 'null'.
In at least some more-or-less current (2009-09-12) browsers (IE 8, FF 3.0.13, Opera 9.64) undefined = 5 is accepted as an assignment, unlike null = 5 in at least one browser. Whatever the detailed explanation, both should be equally unacceptable; the typing-error if (undefined = something) may cause great subsequent confusion.
Anything that looks as if it ought to be immutable ought to be immutable.
It is difficult to discuss, in English, whether undefined is defined or undefined. It should have been called, for example, 'incognitus'. Perhaps the alternative could be eased in.
CPU chips with IEEE 754 decimal floats are appearing. It would be well to specify how JavaScript should handle true decimal arithmetic, while leaving its implementation optional.
Table 2 contains at the beginning of a cell (twice) :- "If the value is an Object it must be a function.". That does not read well. The pronoun "it" should be replaced by the noun to which it is intended to refer.
A single operator £= such that X £= Y would be equivalent to X = (X+1)%Y would be nice, perhaps with X €= Y equivalent to the reverse operation X = (X+Y-1)%Y. As for %, X and Y would usually be positive integers.
This comment is not intended to suggest the actual representations of the operators.
The lack of a direct "div" (integer divide) operator is much regretted. Perhaps "\" could be used for it, with "\=".
The heading should have 'Does-not-equal' ; cf. section 11.9.5
The section has "NOTE ... Numeric comparison can be forced by: a - 0
== b - 0".
Alternatively it can surely be forced by +a == +b.
Examples of unary plus should be beneficial.
That heading would be better written as '( ? : )' since '?:' is not a token.
The section may not include all possible compound assignments ??? perhaps the others are redundant. I have wanted to use at least one apparently not provided, though, and saw no direct alternative.
It is a pity that the string representing the ECMAScript code statement which is the topic of this subsection is the same string as that used for an action internal to the ECMAScript system, as for example in 12.10 step 6. It is much more difficult than it would otherwise be to scan the document to find further information relating to the 'throw' statement. Possibly the word for the "internal" throw could be changed to 'raise'; 'raise' is used only once in the Draft, where a synonym could be used ('give' might do).
When the .toString() method of a variable of type function is called, some browsers give the full source code as written, including layout and comments, whereas others give an expansion of a tokenised form, with a new layout, no comment, and some constant expressions evaluated.
On the whole, I much prefer the as-written form, which is extremely useful when writing about ECMAScript code.
I suggest that toString() here be allowed an argument. If the argument is absent or equivalent to false or zero, the browser should do what it did before. Otherwise, if it is odd, the browser should give the literal form if possible, otherwise something equivalent to false; if it is even, the browser should give the tokenised form if possible, otherwise something equivalent to false.
Needs "returns" plural : has "otherwise it return false".
If this and reduceRight are similar, this should be called reduceLeft.
No String.prototype.substr? B.2.3. I'd prefer it to be retained in full.
Number.MAXINT might be useful, with value 253. Granted, it's easily calculated, by those who know the value.
Not a standards matter; but it would be nice if Microsoft could get this one right. Try 0.007.toFixed(2). MS IE 8 and earlier give 0.00; other browsers give 0.01. Also try, in MS IE, parseFloat on an integer string of, say, 25 digits and on the same string with ".0" appended; and unary plus likewise.
Includes "Although the choice of algorithms is left to the implementation, it is recommended (but not specified by this standard) that implementations use the approximation algorithms for IEEE 754 arithmetic contained in fdlibm, the freely distributable mathematical library from Sun Microsystems (http://www.netlib.org/fdlibm). This specification also requires specific results for certain argument values that represent boundary cases of interest". The link is to a page set dated January 1995.
Even by the time of ECMA 262 3rd Edn, the recommendation ought to have acknowledged that most computers include floating-point instructions corresponding to most or all of what is needed for Math and accurate for IEEE Doubles. An implementor should use those, after verifying their specified or actual accuracy.
(Missing full stop at end of last line of page 152 of FD5.)
This could also be described in Cartesian co-ordinates as the angle from the x-axis of the point (x, y).
A note that for a large range of X, X|0 = Math.floor(X) might be useful; X|0 should be faster.
For this section, see also in JavaScript Random.
I think "pseudo-randomly" should have its hyphen.
It seemed likely though not inevitable that the pseudo-random IEEE Double will be generated by way of a pseudo-random 64-bit unsigned integer. Those can be converted to Double in at least two ways.
(A) Take 53 bits, and use as the mantissa of a Double with positive sign and appropriate exponent; then normalise. Easily implemented efficiently.
(B) Divide by 264 and round to the nearest Double.
Method (A) gives an equally-spaced comb of possible results; the interval is always 2-53; there are 253 possible values.
Method (B) gives a comb which gets finer and finer as the actual values reduce; the interval varies from 2-53 to 2-64; there are many more possible values.
Both are compatible with Draft 15.8.2.14.
I consider Method (A) to give better results (and that, within the life of this Standard, it is possible for the difference to be significant).
I have been told of a JavaScript system which appears to be type (B).
Suggestion : insert as shown in italics, or better : "Returns a number value with positive sign, greater than or equal to 0 but less than 1, chosen randomly or pseudo-randomly with approximately uniform and evenly-spaced distribution over that range, ...".
Some current browsers apparently use only 32-bit generators, or less. How about indicating that full 53-bit performance is appropriate? Recent machines can easily support it.
2009-06-10 : I now know that implementation of Math.random is commonly worse than I thought.
It appears that Math.random can be a security hole. See, via HTML Temporary user tracking in major browsers and Cross-domain information leakage and attacks, a 325kB PDF of the same title, by Amit Klein.
The paper gives considerable information on the internals of Math.random in major browsers.
Therefore, I suggest that the ECMA standard should call for improved Math.random. It should be able to return all and only values N × 2^-53, for integer N such that 0 <= N < 2^53 - 1, with approximately equal probability. The seed should not be generated only from the clock time at start-up; mixing in the readily-available (in PCs) CPU cycle count at start-up would increase security. It should be possible to write, and perhaps read, the full internal state of the generator - useful at least in testing. If the initial seed carries no useful information, reading or deducing it should not add insecurity.
Experience has shown that many coders do not know how best to obtain, using Math.random, a random integer in the range 0 to N-1. I suggest that it would be worth adding that to the language, perhaps as a method Math.randInt(N) or else just as Math.random(N). Code has been found needed in Usenet news:comp.lang.javascript FAQ for example.
Math.random traditionally takes no arguments. It could be enhanced by allowing an argument which could be an Object representing by its properties the internal state of the generator, updated at each call. A user could then, for example, set a specific state in order to get reproducible behaviour for testing. I now (2009-06-21) have substantially completed, in JavaScript Random, such a function.
Given a means of setting the initial state of a reasonably rapid generator from variables, it is desirable to be able to set the variables to random values; but that need not be so fast. If the language were to offer an optional routine to give slow but good random numbers in some machine-dependent manner, then implementors would be encouraged to provide one.
I have read that ECMAScript applications may need to generate GUIDs. That can be done, very badly, by using Math.random. There should be a new and conceptually distinct method which will return a well-formed GUID string. The core of the new method must be very much better than that of Math.random commonly is. Section 15.8.2.14 should include a statement of whether Math.random can be expected to give results good enough for cryptography or GUIDs.
Shuffling is commonly badly done. Therefore, SHUFFLE (and DEAL and DRAW) should be introduced as new methods of Array. Since they can be coded briefly and efficiently in Pascal and JavaScript (using Random(N)), there should be no difficulty in doing likewise in JavaScript engine source code.
JavaScript Random refers.
My general Date work is indexed at Date and Time Index and Links; my JavaScript Date work is at JavaScript Date and Time Introduction; see in particular JavaScript : Object DATE2.
Could there be a case for saying, early on in 15.9, that both local date/time representations and GMT ones are handled? Also, since there is no provision for Leap Seconds, "UTC" is wrong; "GMT" had the right meaning, and "UT" may be formally correct. Personally, I use GMT, as it has the right properties and is well-known.
Most date algorithms use either local or UTC routines, but do not need to use both. One can provide, using ECMA-262-3 code, new methods which call either the Local Civil Time (LCT) routines or the UTC routines, depending on a static variable of a DATE object. Accordingly, one piece of code can be written to do both the UTC and the LCT versions of a task. Tested and OK via DATE2. A native version should be easy to produce and more efficient than my implementation.
The "public" versions of the individual LCT and UTC methods might then be deprecated in Edition 6, and demoted to an appendix in Edition 7 or thereabouts.
This section of the standard defines time value. But there are instances below it of references to that concept but using other words. That is confusing. Also, one should be able to find all such references by searching only for the obvious string. And date/time value or DateTime value would be better - one could then readily distinguish it from references to Date (YMD) or Time (hms).
Paragraph 1 : But "since 01 January, 1970 UTC" commences at the start of 02 January, 1970 UTC. Use instead "since 1970-01-01 00:00:00.000 GMT" or "since 1970 January 01 00:00:00.000 GMT" or "since 1970-01-01.0 GMT". Using "since 1969 GMT" would be accurate but confusing. Similarly elsewhere. Alternatively, "Time is measured in ECMAScript in milliseconds, +0 representing 1970-01-01 00:00:00.000 GMT.". Paragraph 3 is then redundant.
Paragraph 1 : Also the next larger integer, 2^53.
Paragraph 2 : Is it necessary to prohibit values between 8.64e15 and 253 milliseconds ?
Paragraphs 1 & 2 : I see no point in giving the range in years for 253 milliseconds, when it is that for 108 days which matters.
Paragraphs 1, 2, 3 and elsewhere : ISO 8601 notation should be used wherever possible; 1970-01-01 00:00:00 then GMT or UTC or Z. Those who cannot understand it will not be wise enough to understand most of the document.
Correct always for UTC/GMT, not always for LCT.
Cannot those be largely replaced by a reference to ISO 8601?
Something should be said about years before AD 1 - that Astronomers' Notation is used, with years ... -2, -1, 0, 1, 2, ... and positive ones matching AD.
DayFromYear : there is an expression which might be thought better, using I think z = y-1 and DayFromYear = 365*z + Math.floor(z/4) - Math.floor(z/100) + Math.floor(z/400) - 719162
Following material in 15.9.1.3 only applies where Summer Time is not used.
Noteworthy that ISO 8601 differs only in that Sunday is 7 instead of zero. OneToSeven = ZeroToSix | 7 ZeroToSix = OneToSeven % 7 ECMAScript should offer full support for the basics of ISO 8601. That means including ISO Day Number, Week Number, Year Number (best calculated and returned together in an Object) and Ordinal Date (Day of Year).
Uses the term "Time Zone" correctly (which is fairly unusual). At a given geographical location, LocalTZA does not vary with season, but it can be politically altered with time.
The term "Summer Time" is preferred in a majority of countries.
A note of which countries currently cannot be accommodated by those rules would be inappropriate but amusing. Candidates are Iran, Israel, Morocco, Mauritius; I think only Iran & Israel qualify.
Text has "must depend only on four things:" - better : "must depend on at most four things:". Unless it means to exclude Morocco & Mauritius, which seems unnecessary. Israel & Iran have non-Gregorian rules.
To always use the true current algorithm, it is clearly necessary to know the exact moment when the algorithm changes. The 2007 US DST change was defined to occur at the start of 2007-03-01, presumably implicitly in LCT. I think the UK has changed the definition formally from a moment when it first affects the clocks.
If a location changes Summer Time rules twice within 28 normal years, that mapping may not always be possible.
Note that for one hour each year, where Summer Time is used, one hour (or half-hour) of local time does not exist and one exists twice.
The section heading should have "Seconds".
There is an alignment typo, on line 3 !
And 24 HoursPerDay is not always right; it can also be 23, 23.5, 24.5, 25.
I think that it might be efficient to have a routine which returns, from a single calculation, an Object {h: , m: , s: , ms: } and likewise for YMD, YWD, YO.
See ISO 8601:2004; its PDF is free. This standard should not refer to an existing standard in a manner that suggests more compliance than there is. If the intention here is, as it appears to be, just to support JSON, then this standard should cite and use just "JSON", not "ISO". For code supporting ISO 8601:2004 more fully, see DATE2.
"Simplified ISO 8601" is incorrect terminology - should be something like "The ECMAScript version of an ISO 8601 Extended Format is ..." - or change to JSON
The Draft has "The Simplified ISO 8601 format is as follows: YYYY-MM-DDTHH:mm:ss.sssTZ". A Standard should not meddle with the requirements of other Standards. Either that is an ISO 8601 format or it is not an ISO 8601 format.
In "Extended Years" - for ISO 8601, 5-digit years should for convenience be allowed. It will be simpler.
In "Note" - In ISO 8601, T is a separator, not an introducer; it should only be used between a date and a time.
In "Note" - That which may be appended is not a time zone; and it should be possible to append it to a pure date. Christmas Day in Hawaii is almost entirely after Christmas Day in New Zealand - without an Offset, 2009-12-25 covers approximately 48 hours.
In "Note" - "As ... midnight" paragraph : In UTC, and usually in LCT. But, in some locations at the beginning or end of Summer Time, the LCT day may end at 23:00 or start at 01:00.
In "Note" - last paragraph : But GMT & UTC are adequately standardised.
I think that XML uses a very similar date/time format, but with more than three decimal places allowed. Therefore I strongly suggest that code for reading the format described above, and/or for reading true ISO 8601, should be required to accept any reasonable number of decimal places. Coding to allow that must be trivial.
A routine giving an undefined format is not of much use.
The (UTC) seems unhelpful; method toString does not give UTC.
Where arguments are ignored completely, it does not matter how many they are, or what they might represent.
Ends "is set to the current time (UTC).". But normally time is in the range 0 <= T < 24 hours. This is a case for "Date/Time value".
It could be well to specify that YYYY/MM/DD will be recognised - at least five major browsers already comply. It may still be necessary that "77/04/22" be shifted to 1977; but "0077/04/22" should give AD 77.
Recognition of ISO-like input should be liberal; separator "T" or "t" or whitespace, accept Z or UTC or UT or GMT and offset with or without central colon. Even accept a.m./p.m., maybe.
Paragraph 1 :
• "UTC time value" is not defined as such; the "UTC" is
superfluous (or should be attached to other instances of "time value").
And "date" is wrong; I suggest "date/time" or"[current] instant]".
• "The parse function applies the ToString operator to its
argument and interprets the resulting string as a date;" - it seems to
me unreasonable to describe it as a date; a date is normally about 24
hours wide. Applies elsewhere. 15.9.3.3 uses "current time (UTC)".
There should be a method to get, from a Date Object, a string representing it in a format which is fully chosen by the programmer.
It could be useful to be able to get a string formatted for a given different Offset; one might want to display, in Paris, the time in Beijing or Dallas.
In each case, misuse of "time zone". It is the time offset which is intended to be taken into account. Change "in the current time zone" to "with the current time offset" throughout. Each contains "a convenient, human-readable form" - I suggest that it is not sufficiently clear whether and alphabetical part is expected to be in the locale natural language.
If natural language support is to be provided, then it would be useful to require the system to provide arrays of names and abbreviations for months and days-of-week. The latter should have 8 entries, elements 0 and 7 both being for Sunday, which supports both ECMAScript/C numbers and ISO 8601 numbers.
The result when the Date Object holds NaN is not considered; I prefer to get a string "NaN" but some major browsers give "Invalid Date". It should be specified.
Misnamed, should be getTimeOffset. I suggest introducing the name getTimeOffset and strongly deprecating getTimezoneOffset.
Giving just UTC is a grievous and intolerable limitation, for ISO 8601. The LCT value will commonly be wanted. I think that this routine should be renamed "toJSONString" or "toJSONDateTimeString".
First paragraph seems to lack "when called with no argument".
Enumeration of \s characters ?
Current browsers have differing interpretations of RegExp White Space. Numbers of characters accepted : MSIE7, Safari, Chrome : 6 ; Firefox : 22 ; Opera : 24. In my RegExp Feature Testing, 'RegExp \S \s Testing' refers. Therefore I suggest that the Standard could well be more definite in regard to the characters where present browsers differ.
The six \s characters common to all those browsers are \u0009 \u000a \u000b \u000c \u000d \u0020.
Using "word" in conjunction with \w should continue to be avoided.
A strange title for a section dealing with properties that are more-or-less being removed. "Other Properties"? "Deprecated Properties"?
I'd prefer it to be retained in full. Method substr is useful; one often knows the desired length.
That was folly in the first and all subsequent instances; one only needs to calculate FullYear%100.
Likewise; one only needs to add 1900.
Paragraph 1 : "th at" and "name d" appear to contain thin spaces of some sort.
Paragraph referring to Section 15.9.4.2: Date.parse - change ISO to JSON or XML, since the specified capability is so limited in comparison with what ISO 8601 offers.
Especially for those reading the electronic form, I suggest replacing "inside cover" by "previous" or whatever else was intended.
Perhaps IEEE 754 Double arithmetic should become required throughout in the Date Object. In investigating date bugs, I have seen cases where 32-bit days or seconds from 1970 are evidently used.
See Usenet news:CLJ 24 Oct 2007 thread ECMAScript 4+ Date proposals (and DATE2).
In that thread, 25 Oct 2007 :-
"It would also be useful to have a routine which, given a duration in milliseconds, returns [an object holding] the duration expressed in days hours minutes and seconds.
Granted, an intelligent ten-year-old of my generation could do that; but few of the younger programmers seen to approach that standard reliably."
That would take no cognisance of Summer Time. The count should reverse after becoming zero, and the Object could also include a field value 0 for the zero second and +1, -1 on each side of it.
Since ECMAScript can determine (JavaScript Date and Time 2 : Demonstrations), given a correctly-set OS, the approximate longitude, and for places with Summer Time, also the clock change date/times and the hemisphere (N/S), it would be possible to provide a standard Method to return those in an Object.
It could also be useful (and trivial for a browser coder) to return the cloch change information directly obtained from the OS : that might be a TZ string. A Method for that would be allowed to give an OS-dependent return, with perhaps undefined when no useful form was available.
For calculating some holidays, support for Gregorian Easter Sunday would be useful. I have efficient compact code, traceably derived ultimately from the Calendar Act, in The Calculation of Easter Sunday after the Book of Common Prayer of the Church of England.. Other Easter code is in estralgs.txt etc.
Historically at least, document.lastModified has been of uncertain format, often losing information that was present in the RFC-specified Last-Modified header of the HTTP transfer. It should be easy and useful to provide as a static property Date.LastModified holding a read-only string exactly maching the variable part of the corresponding HTTP header line. The format of that header line is exactly specified by an RFC; as far as I know, in all browsers new Date() reads that format correctly, and this standard could explicitly make that a requirement.
In Web page JavaScript : Object DATE2, I have developed a substitute for the native Date object. It should include all that has been suggested above, and more, except where another specific link is given.
One might ask why ECMA's introductory footers include a numeric date which is not in ISO 8601 form, and which therefore is ambiguous. They also include only a partial postal address; Switzerland does not by any means have the only Geneva.