<div># July 24 2012 Meeting Notes</div><div><br></div><div>Present: Yehuda Katz (YK), Luke Hoban (LH), Rick Waldron (RW), Alex Russell (AR), Tom Van Cutsem (TVC), Bill Ticehurst (BT), Brendan Eich (BE), Sam Tobin-Hochstadt (STH), Norbert Lindenberg (NL), Allen Wirfs-Brock (AWB), Doug Crockford (DC), John Neumann (JN), Oliver Hunt (OH), Erik Arvidsson (EA), Dave Herman (DH)</div>

<div><br></div><div><br></div><div>10:00-11:00am</div><div><br></div><div>Discussion of proposed agenda.</div><div><br></div><div>Determine participants required for specific subjects.</div><div><br></div><div><br></div>
<div>
July agenda adopted</div><div><br></div><div>May minutes approved</div><div><br></div><div># 4.1 AWB Presents changes resulting in latest Draft</div><div><br></div><div>Draft related bug filing</div><div>        Increased community participation, a good thing</div>

<div>        Issue with numbers not matching duplicate filings, be aware</div><div><br></div><div><br></div><div>Quasi Literal added to specification</div><div>        Spec issues have arisen, will review </div><div>        </div>

<div><br></div><div>Initial work defining tail call semantics (still need to define tail positions in 13.7)</div><div>        What defines a "tail call" in ES</div><div>        Existing Call forms need to be specified in how they relate to </div>

<div>        tail positions. (call, apply, etc)</div><div><br></div><div>STH: Important that call and apply be treated as tail calls</div><div><br></div><div>YK: and accessors</div><div><br></div><div>STH: Agree. </div><div>

<br></div><div>…discussion of examples</div><div><br></div><div>AWB: Differences between accessor calls as they apply to proxy call traps, not definitively identifiable at syntax level. The function call operator and the call trap.</div>

<div><br></div><div>TVC: Proxy trap calls currently can never be in a tail position (except "apply" and "construct" traps)</div><div><br></div><div>STH: call should be in tail position. Clarification of known call site syntax, per spec.</div>

<div><br></div><div><br></div><div>Summary:</div><div>        Anything that could invoke user written code in a tail position to act as a tail call.</div><div>        </div><div>call, apply, accessors, quasi (interpolation), proxy calls</div>

<div><br></div><div>        We still need to specify the tail positions in the syntax.  There's a start by DH on <a href="http://wiki.ecmascript.org/doku.php?id=harmony:proper_tail_calls">http://wiki.ecmascript.org/doku.php?id=harmony:proper_tail_calls</a> which uses an attribute grammar, but the current spec draft leaves this blank.</div>

<div>        </div><div>Filed: <a href="https://bugs.ecmascript.org/show_bug.cgi?id=590">https://bugs.ecmascript.org/show_bug.cgi?id=590</a></div><div><br></div><div><br></div><div># 4.5 RegEx "Web Reality" </div>

<div>(<a href="http://wiki.ecmascript.org/doku.php?id=strawman:match_web_reality_spec">http://wiki.ecmascript.org/doku.php?id=strawman:match_web_reality_spec</a>)</div><div><br></div><div>Introduction to discussion by Luke Hoban</div>

<div><br></div><div>LH: Attempted to write a guide to make regex specification match current implementation wherein order of production matters. See *15.10.1 Patterns* in above link. </div><div><br></div><div>…Gives specfic examples from 15.10.1 </div>

<div><br></div><div>Discussion between AWB and LH re: semantic annotations and redefinition.</div><div><br></div><div>YK: Do non-web implementations match current spec or web reality?</div><div><br></div><div>AR: Are there any non-web implementations?</div>

<div><br></div><div>YK: Rhino?</div><div><br></div><div>BE: matches reality because based on SpiderMonkey circa 1998</div><div><br></div><div>Test cases? Yes.</div><div><br></div><div>BT: Yes, cases exist in Chakra</div>
<div>
<br></div><div>LH: (Refers to examples)</div><div><br></div><div>NL: Do these affect unicode? We had agreement at previous meeting that web reality changes would not be applied in Unicode mode (/re/u).</div><div><br></div>

<div>LH: This is what regex is in reality… Waldemar did not want to specify because it's too hard to specify, but now the work is done</div><div><br></div><div>AWB: Too hard is not an excuse to not specify, good that the work is now done.</div>

<div><br></div><div>Discussion of "\u" in existing regex - \ug or \u{12} is interpreted, but differently than planned for Unicode mode</div><div><br></div><div>Trailing /u flag?</div><div><br></div><div>Makes grammar more complicated to have \u{...} only if /u flag used. </div>

<div><br></div><div><br></div><div>AWB: Three things to address: Web reality, Unicode support, new extensions</div><div><br></div><div>LH: /u the only way to opt-in to Unicode escapes with curlies, with Unicode extensions.</div>

<div><br></div><div>NL: need to reserve backslash with character for new escapes in the future, e.g. \p for Unicode character properties</div><div><br></div><div>OH: Fairly substantial regex in wild all created with RegExp constructor. </div>

<div><br></div><div>YK: Moving forward: Evangelize using Unicode and tacking "/u" onto all new regex? </div><div><br></div><div>BE, OH, AR: yes.</div><div><br></div><div>Decision: LH and NL to collaborate on integrated proposal</div>

<div><br></div><div><br></div><div><br></div><div># 4.7 Adding forEach to Map and Set</div><div><a href="http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets">http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets</a></div>

<div><br></div><div>Deferred, got to it on third day</div><div><br></div><div><br></div><div># 4.9 getClassNameOf</div><div><br></div><div>BE: Recap, last meeting there was discussion about getting a strawman from YK</div>

<div><br></div><div>YK: I began specifying, but existing questions prevented</div><div><br></div><div>BE: some want to solve not only the typeof null problem, but also "array"</div><div><br></div><div>YK: What is the usecase for Object.isObject</div>

<div><br></div><div>DC: Polymorphic interface</div><div><br></div><div>AWB: "has properties"</div><div><br></div><div>RW: Similar to isNaN: isNull that is only for null</div><div><br></div><div>OH:(Reiterates that we cannot change typeof)</div>

<div><br></div><div>AWB: what is it about host (exotic) objects that need to be differentiated from native (ordinary) objects? </div><div><br></div><div>YK: Reclarification about things that are not objects (in the [object Object] sense) that say they are.</div>

<div><br></div><div>AWB: If we go down this path, can anyone redefine the return value</div><div><br></div><div>YK: My question is:  either always return object Object, or let anyone change to return anything</div><div><br>

</div><div>AWB: Rephrase as "extending toString()". Removing [[Class]] from spec, but now as [[NativeBrand]]. </div><div>The default: exactly as they are today. in ES6, if this property is defined, then use it, if not, use default. </div>

<div><br></div><div>Mixed discussion of real world uses of:</div><div>Object.prototype.toString.call(o)</div><div><br></div><div>BE: 1JS Killed typeof null</div><div><br></div><div><br></div><div>BE, OH: Like the idea of a configurable property to define explicit value of brand</div>

<div><br></div><div><br></div><div>YK: why is what "toString" returns so important?</div><div><br></div><div>AR: 2 things: </div><div>1. Fixing is not easy</div><div>2. How to correctly fix w/o making more surface area for the wrong thing</div>

<div><br></div><div><br></div><div>Summary</div><div><br></div><div>There is worry that changes to spec that affect the return of toString will have adverse impact on existing libraries and users when they encounter new runtime behaviours where the existing behaviour is expected.</div>

<div><br></div><div>Belief that we need a more flexible mechanism, whether it is AWB's configurable property that defaults when not explicitly set, or AR et al trait type test proposal.</div><div><br></div><div>BE, AWB: nominal type tests considered an anti-pattern per Smalltalk, but they happen in JS not only "because they can" -- sometimes because of built-ins you need to know</div>

<div><br></div><div><br></div><div># 6 Internationalization Standard </div><div><br></div><div>Norbert Lindenberg: (Introduction and opening discussion)</div><div><br></div><div>Discussion, re: contributors</div><div><br>

</div><div># 6.1 Last call for feedback before final draft</div><div><br></div><div>Function length values? Using ES5 section 15 rules would cause respecified functions like String.prototype.localeCompare to have larger length values; using ES6 rules would let them keep old values.</div>

<div><br></div><div>Leads into larger discussion about Function length property.</div><div><br></div><div>Decision: Apply ES6 rules to all functions in Internationalization API.</div><div><br></div><div><br></div><div>Numbering system, number formatting system. Would like to reference Unicode Technical Standard 35.</div>

<div><br></div><div><br></div><div>Outstanding issue:</div><div><br></div><div>If you have 4 different impls, 3 of them support a language that you want to support, how can you polyfill the 4th to support the language. </div>

<div><br></div><div>The constructor can re-declared?</div><div><br></div><div>Conclusion: There is no easy way currently, second version of Intl spec will address this.</div><div><br></div><div>Conformance tests being written for test262.</div>

<div><br></div><div>NL will have the final draft prepared for September meeting, but will produce drafts leading up to that meeting.</div><div><br></div><div><br></div><div># 6.2 Microsoft and Google are implementing prototypes</div>

<div><br></div><div># Unicode support</div><div><br></div><div>AWB:</div><div><br></div><div>within curlies: any unicode code point value \u{nnn}</div><div>so essentially three ways within string literal:</div><div>- two old-style escapes, expressing utf16 encoding</div>

<div>- two new-style escapes, expressing utf16 encoding</div><div>- one new-style escape, expressing code point</div><div><br></div><div>BT: treating curlies as utf32 value?</div><div>AWB: curlies contain code point value, which you *could* call utf32</div>

<div><br></div><div>DH: old-style escapes always are a single utf16 code unit, so always .length 1; new-style escapes always are a single Unicode code point, so may have .length 2</div><div><br></div><div>NL: "<<some stupid emoji>>" = "\u{1F601}" = "\uD83D\uDE01" = "\u{D83D}\u{DE01}"</div>

<div><br></div><div>AWB: one point of controversy: what happens with utf16 escape sequences within identifiers</div><div>- no current impl recognizes suppl pair escape sequences for suppl identifier characters</div><div>
- `var <<wacky identifier>> = 12` -- is that a valid identifier?</div>
<div>- `var \u{<<wacky identifier code point>>} = 12` -- is that a valid identifier?</div><div><br></div><div>NL: and, for example, what if it goes in an eval?</div><div><br></div><div>DH: careful! difference between:</div>

<div><br></div><div>eval("var <<emoji>> = 6")</div><div>eval("var \uD83D\uDE01 = 6")</div><div>eval("var \\uD83D\\uDE01 = 6")</div><div><br></div><div>AWB: disallowed:</div><div>
<br>
</div><div>`var \uD83D\uDE01 = 6`</div><div>`eval("var \\uD83D\\uDE01 = 6")`</div><div><br></div><div>allowed:</div><div><br></div><div>`var \u{1F601} = 6`</div><div>`eval("var \\u{1F601} = 6")`</div>
<div>
<br></div><div>DH: any reason to allow those?</div><div><br></div><div>YK: sometimes tools taking Unicode identifiers from other languages and translating to JS</div><div><br></div><div>DC: we have an opportunity to do this right; \u{...} is the right way to think of things</div>

<div><br></div><div>DH: we have eval in the language, so the language thinks of strings as UTF16 and should have a correspondence in the concept of programs</div><div><br></div><div>LH: there's just no strong argument for this inconsistency</div>

<div><br></div><div>DH: there's no real practical value for disallowing; there is potential harm for the inconsistency in causing confusion in an already-complicated space</div><div><br></div><div>DC: the only real value here is for attackers; no normal code uses this</div>

<div><br></div><div>BE: and maybe code generators</div><div><br></div><div>LH: it's just removing an inconsistency that could be a gotcha</div><div><br></div><div>LH: there isn't a codePointLength -- is that intentional?</div>

<div><br></div><div>AWB: since strings are immutable could be precomputed</div><div><br></div><div>DH: which is why you want it to be provided by the engine, so it can optimize (precompute, cache, whatever)</div><div><br>

</div><div>DH: should it be a function, to signal to programmer that it has a potential cost?</div><div><br></div><div>AR: but no other length is a function</div><div><br></div><div>DH: fair enough, just spitballing</div>

<div><br></div><div>AWB: what about code point iteration from end to beginning? and also codePointIndexOf? don't have those yet</div><div><br></div><div># 4.1 (cont) Processing full Unicode Source Code</div><div><br>
</div>
<div>String Value</div><div><br></div><div>Conversion of the input program to code point sequence outside of standard</div><div><br></div><div>Trad. \uxxxx escapes represent a single char, creates a single BMP character, 16bit element</div>

<div><br></div><div>Issue: in string values, ?? (Etherpad is broken) === \u1F601 === \uD83D\uDE01 === \u{D83D}\u{DE01}. In identifiers, ?? ===  \u1F601 !== \uD83D\uDE01 !== \u{D83D}\u{DE01}. Inconsistency that's hard to explain to developers.</div>

<div><br></div><div>DC: This feature is more likely to be used by hackers than developers.</div><div><br></div><div><br></div><div>AWB: Two APIs</div><div><br></div><div>String.fromCodePoint (build string from integer values)</div>

<div><br></div><div>String.prototype.codePointAt</div><div><br></div><div>What's here, valid surrogate pair?</div><div><br></div><div><br></div><div>DH: Mixing the API levels is problematic, should it be scrapped? </div>

<div><br></div><div>…The problem in naming is the "At"</div><div><br></div><div>…If we're going to build code point abstractions, we really need a new data type.</div><div><br></div><div>NL: ICU has iterators for grapheme clusters, words, sentences, lines – all based on UTF-16 indices. Abstractions don't require different indices.</div>

<div><br></div><div><br></div><div>Need more here.</div><div><br></div><div><br></div><div># 4.13 Destructuring Issues</div><div><br></div><div>A. Patterns discussion on es-discuss</div><div><br></div><div>Issue: ToObject() on the RHS?</div>

<div>This is currenty specified and enables things like:</div><div>let {concat, slice} = "";</div><div><br></div><div><br></div><div>This equivalence is desirable and maintain by the current spec:</div><div>let { foo } = { bar: 42 }</div>

<div>===</div><div>let foo = { bar: 42 }.foo;</div><div><br></div><div>A syntax for pattern matching against objects</div><div>match({ bar: 42 }) {</div><div>        case { foo } { console.log("foo") }</div><div>

        default        { console.log("no foo") }</div><div>}</div><div><br></div><div>---------------------------------</div><div><br></div><div>let { ?foo } = {}</div><div>let ?foo = {}.foo  // _wtf_</div><div>

<br></div><div>DH: Pure WAT. Let's pick the most common case and address that. You cannot presume to cover everyone's pet case</div><div><br></div><div>What is the right thing to do.</div><div><br></div><div>DH: Future pattern matching</div>

<div><br></div><div>LH: Reiteration of correct matching vs intention</div><div><br></div><div>More discussion, defer until AR is present</div><div><br></div><div>let { toString: num2str } = 42;</div><div>===</div><div>let num2str = (42).toString;</div>

<div><br></div><div>Consensus without AR is to impute undefined for missing property when destructuring, and if we add pattern matching, use different rules for patterns compared to their destructuring meaning.</div><div>

<br></div><div>BE talked to AR at dinner on day 2, thinks he heard this and may have agreed (to avoid breaking consensus). Need to confirm.</div><div><br></div><div><br></div><div>B. Defaults</div><div><br></div><div><br>

</div><div>Explicit undefined value triggerw use of default value initializer.</div><div><br></div><div><br></div><div>let foo = (x = 5) => x;</div><div><br></div><div>foo(undefined) //  returns undefined by current draft</div>

<div>foo()          // returns 5 by current draft</div><div><br></div><div>Issue:  is this desirable?  dherman and others think an explicit undefined should trigger use of default value.   use case in support</div><div>   function setLevel(newLevel=0) {light.intensity = newLevel}</div>

<div>   function setOptions(options) {</div><div>       setLevel(options.dimmerLevel);  //missing prop returns undefined, should use default</div><div>       setMotorSpeed(options.speed);</div><div>       ...</div><div>    }</div>

<div>    </div><div>    setOptions({speed:5});</div><div><br></div><div>Note same rules are used for both formal parameter default values and destructuring default values.</div><div><br></div><div>let foo = (…x) => x.length;</div>

<div><br></div><div>foo(undefined) // 1</div><div>foo()                // 0</div><div><br></div><div><br></div><div><br></div><div>Need summary.</div><div>decision:  change spec. to make undefine trigger use of default value.</div>

<div><br></div><div><br></div><div>C. Unresolved issues related to iterator naming/access </div><div><br></div><div>1. Be able to destructure things that did not opt-in</div><div>2. No implicit coercion</div><div>3. Array.from</div>

<div><br></div><div>spread works on array-like</div><div>destructuring has rest pattern</div><div><br></div><div><br></div><div>import iterator from "@iter"</div><div><br></div><div>function list(x) {</div><div>

        return iterator in x ?</div><div>                [ y for y of x ] :</div><div>                x;</div><div>}</div><div><br></div><div>[a, …] = list(jQuery(selector));</div><div>[a, …] = list([…]);</div><div>[a, …] = list(function *() { … });</div>

<div><br></div><div><br></div><div>f.call(f, …args) </div><div>same as </div><div>f.apply(f, args);</div><div><br></div><div><br></div><div>Summary:</div><div><br></div><div>(DH)</div><div>iterator is a unique name -- can't be public because iterable test not confined to for-of RHS</div>

<div><br></div><div>Destructing and spread - no iterator protocol.</div><div>(return to existing draft semantics of arraylike — [Cannot be both iterable and array-like])</div><div><br></div><div>Array.from: </div><div>- Will have array-like protocol, now iterable</div>

<div>- Will always return a copy</div><div><br></div><div>Array.from should… (this is a change to current specification)</div><div>1. Attempt to use the iterable protocol, if cannot…</div><div>2. Fall back to using Array-like protocol </div>

<div><br></div><div>(Filed: <a href="https://bugs.ecmascript.org/show_bug.cgi?id=588">https://bugs.ecmascript.org/show_bug.cgi?id=588</a>)</div><div><br></div><div><br></div><div><br></div><div>Continued...</div><div><br>

</div>