2008/10/3 Waldemar Horwat <[EMAIL PROTECTED]>:
> 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
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
