domenic at domenicdenicola.com (2013-07-17T19:00:43.566Z)
On Sat, Jul 13, 2013 at 8:46 PM, Brendan Eich <brendan at mozilla.com> wrote: > We should just add > > http://wiki.ecmascript.org/doku.php?id=strawman:bignums > > to ES7. First, I wholeheartedly agree. JS is increasingly being used as a target of compilation. When I asking people doing so what they biggest pain point is, the lack of support for integers is often the first thing mentioned. That said, there are the usual open issues we'll need to settle, most of which aren't even raised by this strawman. Most important is the same as one of the objections raised about decimal: If we treat each individual new primitive type as a one-off special case, we're digging ourselves a deeper abstraction mechanism hole. We first need something like value proxies, so we understand how unprivileged libraries would define new numeric types -- complex, rational, matrix. Once we understand what the bignum API would look like were it defined by an unprivileged library, we can proceed to add it as a primitive anyway. We can even do so before actually accepting a value proxy proposal if necessary, as long as we've settled what the use-API would be. Is there a corresponding wrapping type? How does this wrapping type relate to Number? I think the pragma is a bad idea but not a terrible idea. The problem is that we have no choice that a floating point number that happens to have an integral value prints as an integer. Given that, it would be confusing to read simple integer literals into a different type. Should bignums toString with the i suffix? In general I would say yes. The biggest argument that they should not is that we should be able to use bignums to index into arrays. Contradicting myself above, if we do support such a pragma, we should also have a JSON.parse option that reads integers into bignums, and one that prints only bignums as integers. This JSON option would also print all floats using only float notation. Were we not introducing TypedArrays until ES7, would we have typedArray.length be a bignum rather than a floating point number? If so, is there anything we can do in ES6 to leave ourselves this option in ES7?
First, I wholeheartedly agree. JS is increasingly being used as a target of compilation. When I asking people doing so what they biggest pain point is, the lack of support for integers is often the first thing mentioned. That said, there are the usual open issues we'll need to settle, most of which aren't even raised by this strawman. Most important is the same as one of the objections raised about decimal: If we treat each individual new primitive type as a one-off special case, we're digging ourselves a deeper abstraction mechanism hole. We first need something like value proxies, so we understand how unprivileged libraries would define new numeric types -- complex, rational, matrix. Once we understand what the bignum API would look like were it defined by an unprivileged library, we can proceed to add it as a primitive anyway. We can even do so before actually accepting a value proxy proposal if necessary, as long as we've settled what the use-API would be. Is there a corresponding wrapping type? How does this wrapping type relate to Number? I think the pragma is a bad idea but not a terrible idea. The problem is that we have no choice that a floating point number that happens to have an integral value prints as an integer. Given that, it would be confusing to read simple integer literals into a different type. Should bignums toString with the i suffix? In general I would say yes. The biggest argument that they should not is that we should be able to use bignums to index into arrays. Contradicting myself above, if we do support such a pragma, we should also have a JSON.parse option that reads integers into bignums, and one that prints only bignums as integers. This JSON option would also print all floats using only float notation. Were we not introducing TypedArrays until ES7, would we have typedArray.length be a bignum rather than a floating point number? If so, is there anything we can do in ES6 to leave ourselves this option in ES7? On Sat, Jul 13, 2013 at 8:46 PM, Brendan Eich <brendan at mozilla.com> wrote: > We should just add > > http://wiki.ecmascript.org/**doku.php?id=strawman:bignums<http://wiki.ecmascript.org/doku.php?id=strawman:bignums> > > to ES7. > > /be > > > Jeff Walden wrote: > >> On 07/12/2013 04:53 PM, Mark S. Miller wrote: >> >>> I would like a better API -- both less likely to be used unsafely and no >>> harder (or not much harder) to use safely. Suggestions? >>> >> >> In C++ you'd want MS's SafeInt, or WTF's CheckedInt, with operator >> overloading and all that jazz. Without operator overloading the best I can >> think of are functions for every operation, that have to be used, and if >> you use the raw operators you take your life into your own hands. >> Definitely not as easy as just doing the math the "normal"-looking way. I >> don't see a super-nice way to do this. :-\ >> >> Jeff >> >> -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130714/13ebac38/attachment-0001.html>