Once again, here are my raw meeting notes.
Waldemar
--------------
Discussion of isNaN and isFinite.
Can/should we fix these in place rather than creating more functions?
Allen: Existing usage is consistent with normal numeric coercions
done by other operators such as -.
Doug: Would it be useful to have something that doesn't do the coercions?
Allen: It would be a convenience.
Erik: Not sure if it's worth the extra API.
Decided to accept the proposal.
String duplication: Accepted proposal, but rejected proposed
arbitrary limits of 255 or 4294967296 repetitions. Per Allen's
comment on wiki, behave as though using ToInteger.
Proxy default handler:
Some trivial bugs in the code: Calling getOwnPropertyDescriptor etc.
with only one argument. desc in "desc.configurable = true" can be
undefined.
set/put/canPut problem discussion.
Allen: Clean up the list of primitive methods and handlers.
MarkM: All existing uses of put can be written in terms of set.
Waldemar: Would want a more generic way of invoking [[set]] rather
than having to instantiate a new default proxy.
Brendan: Issue remains with prototype chain.
Agreed to move this to proposal stage, with some open issues.
Discussion about typeof result strings:
Dave: We should set expectation that typeof can return new things in
the future.
Doug: IE can already return a typeof of "unknown".
Waldemar: If we don't add new return strings, in practice it doesn't
matter what we say in the committee. If we do add new ones on
occasion, then folks will pay more attention.
Brendan, MarkM: should have a "second hand of fingers as backups to break".
MarkM: Trouble with === generalization recurring into records that
contain zeroes or NaNs.
Waldemar: To clarify, I'd very much would want === to be an
equivalence relation but don't think that we can. A couple examples:
- switch (-0) {... case 0: ...}
- x !== x as an idiom for NaN testing
Discussion of MarkM's semicolon insertion proposal in response to
yesterday's meeting notes.
MarkM: Parse with and without virtual semicolon and if both succeed then fail.
Waldemar: How far do you backtrack second parse to see if it fails?
One token? Rest of program?
One token would be tenable; rest of program, not so much.
Example pro:
a()
(function() {...})();
Examples con:
x = a + b
+ c
+ d;
x = a[longindexexpression]
[anotherlongindexexpression];
Brendan: Perhaps it's parentheses that are unique?
Brendan: Make a pragma to turn off semicolon insertion as a strawman.
Dave: Recognize real pragmas, not just string literals.
Do we automatically insert a semicolon after the "no ASI" pragma?
Array create:
Allen would like to eliminate the [[class]] property -- it has too
much undesirable conflation of separate concepts:
- magic length property?
- exploded by Array.concat?
- JSON serialized using [] or {}?
- recognized by Array.isArray?
- postMessage special treatment?
- transmitted via proxies?
Brendan: Make a quasiquote special interest group for brainstorming?
Allen: Semi-annual language innovation workshops, independent of
day-to-day standards process?
Proposals on people's radar for Harmony:
Allen:
private names
enhanced object literals
[[Class]]
Object.hash
math enhancements
array protocols
spec MOP vs. proxy MOP
numerics, operator overloading
MarkM:
classes and traits
soft fields
generative module expressibility (deferred compile time of modules
parametrized by modules)
quasis
better random
concurrency
Function.prototype.toString
simple maps and sets
Dave and Brendan:
records and tuples
expression forms
catch guards
generators
array comprehensions
generator expressions
yield*
modules (also includes global object reform)
module loaders
pattern matching
conditional expressions
enumeration
binary data
pragmas
paren-free
versioning
Waldemar:
guards/types
zero-inheritance classes
Erik:
#-functions
Doug:
modulo operator
Luke:
binary data
Function.create
Tom:
extended Object methods
Alex:
promises/deferred/futures
events
Discussion of Brendan's blog post:
case A:
function f(z) {
return #{x: 42, m: #(a) {a*a}};
}
case B:
function f(z) {
return #{x: 42, m: #(a) {a*a}, m2: #() {z}};
}
r1 = f(1)
r2 = f(2)
r1 === r2 in case A but maybe not in case B
r1 egal r2?
MarkM: Function comparison should not reveal captured values.
NaN/zero equivalence debate again.
Tuples are immutable and don't contain holes.
Waldemar: What's a convenient way of replacing the nth element of a
tuple (to make a new tuple)?
Brendan:
t = #[0, 1, 2]
u = #[t[0], 5, t[2]] === #[0, 5, 2]
v = #[...t[0:2], 6] === #[0, 1, 6]
How shallow is #? Do we need the #'s for the getter and setter below?
#{get #p() {...},
set #p(q) {...},
oldSchool: function() ...,
#newSchool() {"Yay!"}
}
Declaration syntax:
const #foo(x) {x} // Redundant const?
let #foo(x) {x}
var #bar(y) {y.z = #() {bar}} // Illegal?
#() {} // expression
#f() {} // expression or declaration
MarkM and Waldemar would prefer #f() to default to const-bind rather
than let-bind. General feeling in that direction.
Implicit block-hoisting for mutual recursion?
Lexical «this»: If #-functions are «this»-transparent, then can't use
them as methods. Any way to override?
Dave: #(this, x, y) {...}
Allen: #(this: x, y) {...}
Consensus semantics, regardless of syntax choice for #-functions'
«this» parameter:
- If you don't mention «this» as a parameter then you always get
«this» from the outer lexical scope.
- If you do mention it then you always get «this» from the call site,
or undefined if it's not called using the . notation or an equivalent.
Where do #-functions inherit from? Do they have call and apply methods?
Discussion of how to refer to obsolete features in the new spec. We
don't want to have to point to ES5.1 to describe things like «with».
Also there can be shared heaps where you can call a legacy function
that uses «with» and is stored in a variable in a module or other new
feature.
Can we put «with» into Annex B?
MarkM: There is a cost to maintaining spec compatibility with «with»
and global objects: Global environment records.
Brendan: We have to do this anyway for DOM event handlers.
Upcoming TC39 meetings:
Mar 22-24 (3 days for Harmony), at Google San Francisco
May 24-26, at UCSC
July 26-28 or 27-28 at Microsoft
September 28-29 at Mozilla
November at Apple
Thank you Doug and Yahoo for hosting!