March 29 meeting notes

Waldemar Horwat waldemar at
Thu Mar 29 17:02:22 PDT 2012

Rough notes from today's meeting.


ES 5.1 quirks in defining globals when the global object's prototype
already contains a property with the same name:
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:
We should correct this in the errata.  MarkM might have more comments
but he's not here.

Luke: 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.
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.

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
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
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.

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.

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.

More information about the es-discuss mailing list