Rough notes from today's meeting. Waldemar ------- ES 5.1 quirks in defining globals when the global object's prototype already contains a property with the same name: https://bugs.ecmascript.org/show_bug.cgi?id=78 Waldemar: What if the prototype contains a getter or setter? Doesn't matter for the purpose of defining globals. Agreed on the solution proposed in the bug. John: Do we have a process for tracking ES5.1 errata? Allen: Yes. John: WIll try to get an official errata on the ECMA site. Strict function caller leak: https://bugs.ecmascript.org/show_bug.cgi?id=310 We should correct this in the errata. MarkM might have more comments but he's not here. Luke: 15.10.4.1 Regexp.source on empty regexps on all browsers returns the empty string instead of (?:), which is incompatible with the spec text. That was a change to the spec in ES5 but browsers didn't obey it. Allen, Waldemar: This isn't a spec bug. It was an intentional change. Luke: It breaks prototype.js. DaveH: If this is the only breakage, change the spec to insert the regexp source into /(?: and )/ instead of / and /. Waldemar: It's not the only problem. Escaping of slashes is also a problem here. Luke: Browsers diverge here. Firefox is the only browser that does escaping. Debated. No consensus. David Fugate: Test262 update slideshow Microsoft sources now include ECMA copyright boilerplate instead of Microsoft's. MarkM will do likewise for Google sources. 19 new bugs 26 bugs resolved Prepopulated bug reports International402 mini-suite framework now (quietly) live, with one fake test Bill Ticehurst will replace David Fugate's role on Test262. Development focus will shift to ES6 tests. Allen: Section numbers will change in ES6, which will impact test suite organization. Norbert: Internationalization Final draft won't make it for June. Will try for December. Allen reviewed half of the spec and had lots of substantial comments. There are quite a number of fixes that need to be made to the spec. Discussion about implementations and overspecification vs. underspecification. MarkM: Quick follow-up on TCP correspondence from yesterday. What should var do? MarkM proposed that var be statically rejected if it would cross a closure boundary. Waldemar: Since we gave up on TCP, => should work just like a function except for 'this'. Discussion cut off by Luke, since it looks like it won't be a quick one. Discussion of hypot, hypot2. hypot is the square root of the sum of squares and takes either two or three arguments. hypot2 is the sum of squares and takes either two or three arguments. Waldemar: How is hypot2 better than just doing x*x + y*y? Luke: It's just ergonomics. General reluctance about the hypot2 name because it looks like the 2 means two arguments (as in atan2). Some debate about other function names (hypotSq? sumOfSquares?). MarkM: How is hypot better than sqrt(x*x + y*y)? It's potentially more efficient and more accurate. It is widespread in numeric libraries. Consensus: hypot will support just two or three arguments. hypot2 dropped. Waldemar, MarkM: Why not one or zero arguments? It would be 0 for zero arguments and abs for one argument. Allen, DaveH: If you pass one argument to hypot, you'll get NaN. Luke: It's not variadic. Waldemar: Why isn't it variadic? Luke: 2 or 3 is the 99% use case. Waldemar: 2 or 3 arguments is the 99% use case for max. Waldemar: If it's not variadic and takes only 2 or 3 arguments, you'll get silent mistakes. If you pass in four arguments, you'll get the hypot of the first three, and the last one will be silently ignored. That's bad. Luke: Will go back to the experts to explore implementing variadic hypot. Add parseInt and parseFloat to Number, matching isNaN and isFinite? Use the name Number.parse instead of Number.parseFloat? Should these functions be specified as independent functions from the existing global parseInt and parseFloat, or should they be the same function objects? Consensus: Not duplicting parseInt and parseFloat into Number. May consider doing a Number.parse in the future. Math.cbrt cube root: Handles negatives, more accurate than pow. Approved. Naming: Math.sign vs. Math.signum? Sticking with Math.sign. Should the spec try to enforce accuracy? No. None of the existing math libraries spec accuracy. MIN_VALUE is 0 on ARM implementations because they don't represent denorms. This is a severe spec violation. However, apparently turning off denorms is a major power savings on ARM. Allen, Waldemar: MIN_VALUE must be a nonzero value. If a platform doesn't represent denorms, it should make MIN_VALUE be the smallest positive normalized number on that platform. Number.toInteger: Just does the internal ToInteger. Not the same as floor. Renamed it to toInt. Count leading zeros: Number.clz. Consensus that we want it. Should we include "32" in the name? Waldemar: "32" not needed in name. None of the other bit operators include "32" in the name. MarkM: Prefers clz32 but doesn't feel strongly. Hex floating point literals: Waldemar: Other languages include these things. They're rarely used but when you want one, you really want one. Use cases are similar to that of hex literals. Will explore adding them. MarkM: 0x3.p1 currently evaluates to undefined. This would be a breaking change. Waldemar: Not clear anyone would notice. How did other languages deal with this? Relocated and rescheduled meetings: May 21-23 Mozilla, Mountain View (May 21 is internationalization) Sep 25-26 Northeastern, Boston The July and November meetings are the same are previously scheduled. DaveH's presentation about module loaders Discussion about cross-origin problems and modeling iframes About loader providing a function to define the entire set of built-ins: Allen: A lot of intrinsics refer to the built-ins. The above function defines the ones that ECMAScript knows about. What about other, implementation-specific ones? Have the environment provide a way for making environments that include such things? Luke: Objections related to WebIDL [I didn't follow the logic] Discussion about the role ECMAScript should play in the hierarchy of web infrastructure. Waldemar: Is there any notion of a parent environment, other than whatever environment intrinsics get the built-ins from? (quietly hoping the answer is no) DaveH: No. Waldemar: What about the dynamic craziness related to inner and outer window objects? DaveH: Will need extra hooks for that. Waldemar: What creates new intrinsic worlds? DaveH: Creating a Loader does, as in: l = new Loader(System, {intrinsics: null}); // Can also specify existing intrinsics to share a world a = l.eval("[]"); Object.getPrototypeOf(a) != Array.prototype b = l.eval("[]"); Object.getPrototypeOf(b) != Array.prototype Object.getPrototypeOf(b) === Object.getPrototypeOf(a) Allen: Can DefineBuiltIns be called any time? DaveH: It can be called on any object at any time. Don't want to get now into esoterica of what happens if there are existing properties, setters, etc. DaveH: Imperative module replacement example: @websockets exists as version 1. An implementation wants to improve it to v2: import "@websockets" as ws; System.set("@websockets", polyfills(ws)); Waldemar: What can you provide to the intrinsics parameter of the Loader constructor, other than the previously covered examples of null and another Loader? DaveH: Nothing else is allowed there. Waldemar, Luke: Then we'll need a notion of a loader type just like we have a notion of an array type. At some point we'll need to say what happens when you pass an object that inherits from a Loader, a proxied Loader, etc. Module syntax alternatives: module x at "foo.js" module x = "foo.js" module "foo.js" as x module x at "foo.js" Don't have time to discuss these now. Unicode presentation In some places ES5.1 treats unicode characters as arbitrary 16-bit chunks. In other places it has special provisions for surrogate pairs. For much text processing it doesn't matter; either works. The trouble points are: - Supplementary characters within source code identifiers - Regular expressions - String comparison - Case conversion Norbert's alternatives: 1. UTF-32 strings 2. UTF-32 or UTF-16 strings Waldemar: Either of these would be nightmares because they'd provide two different ways of encoding the same supplementary character, and by Murphy's Law you'd get the wrong one at the most inconvenient time. Wasted a lot of time in Perl which has this problem. A far better solution would be to keep representation as always UTF-16 and just fix the functions to understand UTF-16 better. Olivier: For ECMAScript to adopt the UTF-32 model, you'd need an amazingly compelling reason that would blow all other ones out of the water. Consensus: No one wants UTF-32 strings. Norbert's favored third option: Stick with UTF-16, change functions to understand UTF-16. MarkM: Careful about breaking compatibility! Change functions or create new ones? Regular expressions: /u mode that matches via UTF-16 code points instead of code units. /./ would match a code point; supplementaries can be in ranges. Clear that this must be done via a mode; this would break too much stuff without a mode such as /u. Waldemar: Why not graphemes? Nebojša: The Unicode folks tried it; it became too difficult. Case conversion UTF-16 fixes are uncontroversial? Waldemar: Not so. When designing ES3 we intentionally disabled some Unicode case conversions to avoid nasty surprises. For example, we wanted /[a-z]/i to match only the ASCII letters. Had we allowed the true Unicode conversions, this would also match the non-ASCII Turkish dotless lower-case i (ı) or upper-case dotted I(İ). There were similar issues around ß expanding into SS. How will we deal with situations like this with /u? Make /u be the little red switch for: 1. Unicode code point semantics 2. Unicode based \d\D\w\W\b\B 3. Unicode case folding 4. Remove some/all identity escapes to allow \p, \X, \N 5. Don't match web reality? Can we do only 1+3+4+5, without 2? Waldemar: That makes no sense. Given 3, you shouldn't expect \w to match the same characters as in non-/u mode because, at the least, /\w/i will match ı or İ. Consensus on doing 1+3+4+5. 2 needs discussion. < and > will work as they do now on strings -- compare code units as unsigned 16-bit integers. trim: There are currently no supplementary white space characters, so we can redefine it to support supplementary characters without breaking anything. toLowerCase and toUpperCase: Safari already converts supplementary characters with apparently no ill effects. Consensus on redefining these to work properly on supplementary characters. Base the spec on Unicode 5.1. Implementations will be permitted to support later versions if they choose. String.fromCodePoint(cp0, cp1, ...) This accepts integers between 0 and 0x10FFFF. If the integer is in the surrogate range, it will produce an unpaired surrogate. String.prototype.codePointAt(pos) Here pos is the code *unit* position. If it's the second surrogate of a pair or an unpaired starting surrogate, it will return the code unit of the surrogate. String.prototype.[iterator] Should return code point strings (of length 1 or 2), not numbers. Waldemar: Would also want an iterator for graphemes. DaveH: The default iterator should return code point substrings. Code point escape: "\u{20BB7}" === "\uD842\uDFB7" V8 doesn't currently throw a syntax error for \u{, but that will get fixed. Exclude 0xD800-0xDFFF? No. Maximally minimal classes: Luke: These aren't good enough to be a net win. Waldemar: These don't address the hard problems we need to solve. Concerned about both future-hostility (making it cumbersome for future classes to declare, say, object layout without cumbersome syntax by taking over, say, const syntax) and putting developers into a quandry -- if they want to do anything more sophisticated, they'll need to refactor their code base away from these classes. Unless one choice is clearly superior, having two choices (traditional and extended object literals) is better than having three (traditional, extended object literals, and minimal classes). Minimal classes currently don't carry their weight over extended object literals. Perhaps they can evolve into something that carries its weight, but it would be more than just bikeshedding. Alex: We need to do something. Debated without resolution. Discussion about events/asynchrony/observers.