Int64

8,017 views

Published on

My talk to TC39 on Int64, Uint64, and beyond (user-defined value types, with operators and literal support) for JavaScript.

Published in: Software

Int64

  1. 1. JS Brendan Eich Brave Software @BrendanEich Int64 & More
  2. 2. Brendan Eich Brave Software @BrendanEich Always bet on JS There are only two kinds of languages: the ones people complain about and the ones nobody uses. — Bjarne Stroustrup
  3. 3. Always bet on Brendan Eich Brave Software @ BrendanEich JS Previous value/operator/suffix thinking… • Int64(0) ==> 0L // as in C# • Uint64(0) ==> 0UL // ditto • Float32(0) ==> 0f // ditto • BigInt(0) ==> 0N // N to avoid i/I • Decimal(0) ==> 0m // m or M, C/F# • User-defined suffixes and operators: | ^ & == < <= << >> >>> + - * / % ~ ToBoolean unary- unary+
  4. 4. Always bet on Brendan Eich Brave Software @ BrendanEich JS Time passed, SIMD faded, new plan needed • Old plan was to build on SIMD landing in living spec.html • I hoped we would get more general “value type” semantics that way • But time matters; as Waldemar said in July, “we should just do Int64” • And @mikeal and I said exact same thing to each other in September • Insight: inducting from hardcoded Int64/Uint64 (with future-proofing) is strictly better than chained risk and complexity of layering on SIMD • This slide deck presents the status quo and sketches future proofs
  5. 5. Always bet on Brendan Eich Brave Software @ BrendanEich JS The @littledan / @brendan BBQ design • After a BBQ joint after-meeting in January 2016 near PayPal, @littledan and I worked out (written up via Twitter DM) a better direct (no SIMD) plan, which is worth a recap for its constraints • We agreed on no implicit conversions, so binary operator dispatch needs no new magic: runtime semantics throw rather than convert so both operands have same Type • Unary operators could be single-dispatch or 1-ary functions • Literals and operators are separate proposals, details mostly TBD
  6. 6. Always bet on Brendan Eich Brave Software @ BrendanEich JS Notable future-proofing problem: ToBoolean • Int64 and Uint64 zero values must be “falsy”, while SIMD all-zero vectors are truthy • Old sketch had ToBoolean operator on deck, but it would have to be infallible, or optimizations suffer fatally (per Andreas Rossberg) • New future-proof idea: numeric types (“value types”) declare their canonical zero value (arithmetic identity; one of N in “zero cohort”) • Bonus: also requiring numeric types to declare canonical unit (one, multiplicative identity) wins for ++/— consistency and simplicity
  7. 7. Always bet on Brendan Eich Brave Software @ BrendanEich JS Consequences/examples for Int64 usage • 1L + 2L // 3L • let x = 4; console.log(x * 5L) // TypeError • console.log(Int64(x) * 5L) // 20L • 0x1FFFFFFFFFFUL * 2L // TypeError • 0x1FFFFFFFFFFUL * 2UL // OK • 0x1FFFFFFFFFFUL * Uint64(scale) // also OK
  8. 8. Always bet on Brendan Eich Brave Software @ BrendanEich JS Spec.html plan of attack and status • Split “6.1.6 The Number Type” into subclauses of new Numeric Types clause for Number, Int64, and Uint64 • Split “20.1 Number Objects” into subclauses of new Numeric Objects clause for Number, Int64, and Uint64 constructors/prototypes/etc. • Check all ToNumber uses to see which ones should be ToNumeric • Refactor 12 Expressions semantics to delegate to Type(x)::op (see next) • Revise Number uses such as SameValueNonNumber carefully (in that case to be SameValueNonNumeric)
  9. 9. Always bet on Brendan Eich Brave Software @ BrendanEich JS Future possible “value class” syntax • value class Decimal {
 constructor(x) {…}
 static zero = Decimal(0);
 static unit = Decimal(1);
 static [Symbol.unaryMinus](x) {…}
 static [Symbol.bitwiseNOT](x) {…}
 // etc…
 static [Symbol.add](x, y) {…}
 static [Symbol.subtract](x, y) {…}
 // etc…
 }
  10. 10. Always bet on Brendan Eich Brave Software @ BrendanEich JS Future possible literal suffix support • value class Decimal {
 suffix m = fromLiteral;
 suffix M = fromLiteral;
 
 static fromLiteral(s) {…} // may throw
 
 // etc…
 }
 let three = 3M; // m and M in scope too • Question: allow RegExp for early error on invalid literal?
  11. 11. Always bet on Brendan Eich Brave Software @ BrendanEich JS Regular expressions for early errors? • /(d{1,19}|
 17d{18}|
 18[0-3]d{17}|
 184[0-3]d{16}|
 1844[0-5]d{15}|
 ...
 18446744073709551615)
 UL/ • Very ugly, hard to handle other radixes, etc. Just say no! Let user- defined numeric types’ literals throw at runtime if malformed
  12. 12. Brendan Eich Brave Software @BrendanEich Always bet on JS Spec Tour
  13. 13. Always bet on Brendan Eich Brave Software @ BrendanEich JS Feedback requests and next steps • Publish a browsable modified spec via brendaneich.github.io
 (may move to tc39.github.io - stay tuned on Twitter!) • Auto-generate an ins/del version of https://github.com/brendaneich/ ecma262/spec.html and publish via gh-pages • Finish “20.1 Numeric Objects” spec changes • Incorporate feedback on detailed changes in published spec
 e.g., known bugs on 0L / 0L, 2L ** -3L, etc. to fix • Propose operators and (separate, later) suffixes/value classes

×