September TC39 meeting notes

Igor Bukanov igor at mir2.org
Fri Oct 3 13:33:22 PDT 2008


2008/10/3 Waldemar Horwat <waldemar at google.com>:
> An open issue is whether const violations should be compile or run-time errors.  Clearly some of them are undecidable and can only be reported at run-time, but what about the clear-cut cases?
>
> {
>  a = x;
>  const x = 2;
> }

It would be nice if a compilation error is reported for

  const x = x + 1;

This way ECMAScript can beat C++ where

const int i = i + 1;

is syntactically valid and the language does not require any
diagnostic from the implementation.

Regards, Igor



>
> - <Object.clone> was proposed.  Waldemar shot it down due to various technical deficiencies and the committee agreed.
>
> - A syntactic rule was proposed to disallow any statement following a <return>, <break>, <continue>, or <throw> statement in order to cut down on errors.  Waldemar pointed out that this would fire for non-dead code such as:
>
>  if (x)
>   ...
>  else
>   return z;
>  foo();
>
> where foo() isn't dead at all.  Other legitimate places to have statements are after a <break> in a <switch>.  There wasn't much desire to change its semantics so that it would look for dead code (that would require specifying whether ... can proceed or not), so it was dropped.
>
> - We were wondering why ES4 had a version of <eval> that did not capture the enclosing scope.  This does not appear to be permitted by ES3, which requires that <eval> either evaluate in the current scope or throw an EvalError.
>
> - The contained <statement> inside a labeled statement should be a <substatement> in the grammar.
>
> - In strict mode, a variable reference inside a nested scope must not evaluate to a Reference whose base is null rather than a Reference to a property of the global object.  The latter would prohibit legitimate references to Window.foo inside a function.
>
> - Discussion about syntax of <use strict> directive.  Most favored option is the string literal "use strict" or "use strict,xxxxx" where xxxxx are arbitrary characters at the beginning of the program.
>
> - The semantics of Function.bind were essentially broken and need to be rewritten.  We also changed its semantics so that bind works exactly as though the additional arguments were supplied at the point of the call, which means that you can use bound functions with both function calls and the <new> operator and have them behave as expected.
>
> - Dropped efforts to reflect the names of parameters.  Many of the ones in the ES3.1 spec have names that are convenient for the algorithm writeups but don't make sense otherwise:  <Object.defineProperty> would have the parameters ["O", "P", "Attributes"].  This also wouldn't extend to the rest parameters that we'll introduce in ES-Harmony, so it's premature to standardize it now.
>
> 11.9.3:  Step 15 on is dead code.
> Step 19 is dead code.
>
> 15.13.1.1:  What's a 34 digit integer?  For example, 7 is not a 34 digit integer.
>
> 15.12.1:  What does it mean to parse 1?
>
> 15.12.2:  What does it mean to contain cycles?  What if the cycle is filtered out?  What if the object modifies itself as it's being read (due to getters or side effects from toJSON routines)?
>
>
> DECIMAL AND IEEE 754-2008
>
> Mike Cowlishaw gave a presentation about Decimal and the IEEE 754-2008 standard which replaces IEEE 754-1985.  New things in there (most of which apply to both binary and decimal floating-point values) include:
>
> - New 64 and 128-bit decimal types and 128-bit binary type.  The decimal types each have two incompatible representations.
> - Hexadecimal float literals
> - Round-to-nearest-ties-away-from-zero mode
> - Fused multiply-add
> - minnum and maxnum (min and max that ignore NaNs)
> - Number-string conversions now must be correctly rounded.  ES3 already specified that.
> - Classification routines (isNaN, isFinite, etc.)
> - quantize and sameQuantum
> - Signed NaNs
> - 36 trigonometric and such functions which must be correctly rounded to the last bit.  Apparently that's now possible to do, although nobody has actually done for the power function.  Luckily these don't have to set the inexact flag correctly ;-).
>
> Most of the above are mandatory.  Making things mandatory even where they don't necessarily apply seems to be the culture of the IEEE 754 committee.
>
> Deleted from IEEE 754:
>
> - Some ways of detecting underflows
> - Traps are no longer mandatory
>
> Mike Cowlishaw published a decFloats C package under an MIT-style open source license:  http://speleotrove.com/decimal
>
>
> Mike Cowlishaw's preferred semantics of Decimal keeps track of trailing zeroes in some ways that several in the committee consider bizarre:
>
>  1.00 + 1  -->  2.00
>  1e12 - 1e12  -->  0e12
>  5 + 5  -->  10
>  1/.1  -->  1e1
>  1/3 - 1/3  -->  0e-34
>
> The values 10 and 1e1 are operationally different.  This causes problems for array lookups where the index is converted to a string:  a[1e4] and a[100*100] would refer to different elements.  IBM gave in on this point and we all agreed to not track trailing zeros (i.e. distinguish among cohort members) at all in ECMAScript.
>
> The "m" decimal literal suffix is in for ES3.1.  It's the only non-downwards-compatible-with-existing-browsers syntax change in that spec.  The spec needs to be updated to include it.
>
> We discussed and agreed that four of the Math routines (min, max, abs, round) should work on both binary and decimal floats in the natural way.  The other ones can coerce to and return only binary floats.
>
> Sam is implementing Decimal in V8 (and Mozilla?).
>
> Waldemar reviewed the current writeup of Decimal and struggled to understand it.  We now agree on what the behavior should be, but pretty much every section of the writeup needs to be corrected or rewritten.  Sam will do the work and Waldemar will review.
>
>
> ES-HARMONY
>
> We spent most of Friday on ES-Harmony, with a long discussion about the role of types.  We agreed that having types be symbols or badges ("interfaces") that some classes can export and can be used to annotate variables and parameters would be a good direction to follow.  We got at least tentative agreement on:
> - Types should be sound.  If <a> has type T, and no one changes <a>, then <a> should continue to have type T.
> - There should be a mechanism for requesting a concrete type (instead of anyone who claims to implement an interface) in situations that call for it.  The simplest way to do this would be to allow classes to be used as types (in addition to interfaces), but that's still considered controversial.  Other possibilities include some way of "freezing" a badge.  I hope we can make a bit faster progress on this.
>
>
> UPCOMING MEETINGS
>
> (I assume that the first day of each meeting is for the secure scripting subgroup.)
>
> Nov 18-20, Royal Kona Resort, Hawaii  (heh, in today's economy the hotels there are cheaper than in Redmond)
> Jan 27-29, Google Mountain View
> Mar 24-26, Washington DC
>
>
>   Waldemar
> _______________________________________________
> Es-discuss mailing list
> Es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>


More information about the Es-discuss mailing list