Beautiful!
- I would leave typeof as it is. But there should be a proposal for a strategy
on how to clean up the whole instanceof/typeof mess. Possibilities: just a set
of best practices, a new operator, etc.
- There should be literals for ints, but I would have at most two kinds – for
whatever is considered most common, e.g.:
let a = -123i; // int
let b = -123l; // long
Rationale: There are only a few ways in which integers are normally used,
those should be convenient, especially for newbies. In contract, for scientific
computing, bignum(500) should not be a problem.
On Mar 20, 2012, at 5:04 , 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!
>
> Dave
>
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
--
Dr. Axel Rauschmayer
[email protected]
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
