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
