SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.
SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.
Successfully reported this slideshow.
Activate your 14 day free trial to unlock unlimited reading.
1.
JS
Brendan Eich
Brave Software
@BrendanEich
Int64 & More
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Brendan Eich Brave Software @BrendanEich
Always bet on JS
Spec Tour
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