David Herman wrote:
I had a great conversation today with my colleagues Michael Bebenita and Shu-Yu Guo, and we came up with what I think is a nicely conservative way to add new kinds of numbers to JS without breaking the intuition that JS has only one type of primitive numbers.tl;dr: Pure, immutable objects that can be optimized to unboxed integers. Examples: let x = uint64(17); let y = uint64(17); console.log(x === y) // true console.log(typeof x) // "object" console.log(Object.isValue(x)) // true console.log(Object.isValue({})) // false function factorial(n) { return n<= 1 ? bignum(1) : n * factorial(n - 1); } console.log(factorial(bignum(500))); // 122013682599111006870123878542304692625357434280319284219241 // 358838584537315388199760549644750220328186301361647714820358 // 416337872207817720048078520515932928547790757193933060377296 // 085908627042917454788242491272634430567017327076946106280231 // 045264421887878946575477714986349436778103764427403382736539 // 747138647787849543848959553753799042324106127132698432774571 // 554630997720278101456108118837370953101635632443298702956389 // 662891165897476957208792692887128178007026517450776841071962 // 439039432253642260523494585012991857150124870696156814162535 // 905669342381300885624924689156412677565448188650659384795177 // 536089400574523894033579847636394490531306232374906644504882 // 466507594673586207463792518420045936969298102226397195259719 // 094521782333175693458150855233282076282002340262690789834245 // 171200620771464097945611612762914595123722991334016955236385 // 094288559201872743379517301458635757082835578015873543276888 // 868012039988238470215146760544540766353598417443048012893831 // 389688163948746965881750450692636533817505547812864000000000 // 000000000000000000000000000000000000000000000000000000000000 // 0000000000000000000000000000000000000000000000000000000 By defining new object types that are immutable, implementations are free to choose among many representations. They can copy the data or share references whenever they want. Since the integers encapsulate only their bits, optimizing implementations can use a 64-bit integer payload. And fully unboxed representations can literally be 64 bit integers (at least, in optimized code where types have been properly inferred). Finally, it's possible to partially evaluate constructors like uint64(17) because the constructor is pure. So even if we didn't have custom literal syntax like 17u64 (which, incidentally, we could), we should still be able to get the same performance. This proposal involves one major change in semantics: the built-in operators have to be overloaded to handle the new types. Rather than go all the way towards user-defined value types, though, I've stuck for now with just a fixed set of built-in ones. It's forward-compatible with user-defined overloading, in case we ever wanted to go all the way. But the nice thing is, since they are all just objects, there's no shame in having a multiplicity of new types, including: * uint8, int8 * uint16, int16 * uint32, int32 * uint64, int64<-- hey everyone, look at this, this is the important part, right here * bignums * IEEE754r decimal * complex numbers (if anyone cares?) * exact rationals (a bridge too far?) For all of these, the answer to `typeof` is still just "object". For the most part, they just feel like a nice "batteries included" library. There's a rough draft of the strawman here: http://wiki.ecmascript.org/doku.php?id=strawman:value_objects Comments welcome!
Hm, I feel a bit conservative... I think having single number type has its pluses.
I'd only include bignum and added MAX_INT (and probably LIMIT_INT_POWER2 and LIMIT_INT_POWER10) to Number. If there is a chance that IEEE754r will be good enough to adopt in next five years, I'd just update Number to be 128bit and so MAX_INT gets higher as well as LIMIT_INT_POWER2 (that goes well beyond 64) and LIMIT_INT_POWER10, so they will have their int64 and uint64 there.
I understand lots of apps want "native" int64 as soon as possible, but I do not like "uint64" etc. "types" - they are too technical, there are lots of them, one then must check what conversions are safe ... whatever.
Dave
Herby _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
