Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Int64

9,426 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

×