search

elm-lang / elm-plans

no longer in use, just want to keep discussions around
BSD 3-Clause "New" or "Revised" License
29 stars 1 forks source link

Integrate support for BigInt #10

Closed ryepesg closed 9 years ago

ryepesg commented 9 years ago

Motivation

Elm is a beginner friendly language (this is the reason we have not higher kinded types). I think the integer's limits are not expressed in the documentation because of the complexity of the topic, and people coming from other high level languages doesn't expect to deal with that specific details.

This proposal attempts to codify the ideas from this thread. This would be a breaking change to core, but no change to the language itself.

Proposed Change

Current implementation overflows:

> 123123517235172351623 + 1
-6003691280794509000 : number

JavaScript doesn't deal with BigNumbers, so the only programs broken programs are those who already had overflows bugs. The expected (even in client side languages like ClojureScript or Scala.js) result is:

Prelude> 123123517235172351623 + 1
123123517235172351624

Next Steps

To evaluate implementations like https://github.com/maxsnew/BigInt.

rtfeldman commented 9 years ago

Can you be more specific about what your proposal is? A "Proposed Change" and "Motivation" section like in https://github.com/elm-lang/elm-plans/issues/7 would greatly help clarify.

mgold commented 9 years ago

"Expected" if you come from the server. On the client, this is JS numbers. Even just 123123517235172351623 evaluates to 123123517235172340000 is JS.

It would be possible to, say, represent larger numbers as arrays or something, but without a concrete use case for numbers that big, I don't see the point in making things more complicated.

ryepesg commented 9 years ago

Thank you for the comments. I updated the proposal accordingly.

rtfeldman commented 9 years ago

I could see someone writing a BigNumber library for Elm, but I would not want it to be the default implementation for numbers.

The performance cost of wrapping every single number is far more concerning to me than the imprecision of JS doubles!

evancz commented 9 years ago

I'm in the process of closing this repo down. I think this is best as a library. The vast majority of languages just do this so its fast and there are no issues. I don't have strong enough feelings about this topic to really choose a side, so I am going to choose the side that has a better track record.

I think it'd be cool to have a BigInt library though, for folks who are doing that sort of computation.

edgerunner commented 4 years ago

Now that ES2020 has its native BigInt support, does it make sense to base the Elm's core Int on that? I think it would help to do away with oddities of the JS floating point numbers.