Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

currently unrepresentable numbers #27

Closed
xtuc opened this issue Jan 11, 2018 · 7 comments
Closed

currently unrepresentable numbers #27

xtuc opened this issue Jan 11, 2018 · 7 comments

Comments

@xtuc
Copy link

xtuc commented Jan 11, 2018

While I agree to specify the following types:

int64
uint64

They are not representable in JavaScript since numbers are 64 bits float (using the IEEE 754 standard).

What should be the behavior of the engine when handling values of that type? That might also confuse the user who annotated the value.

@Avol-V
Copy link

Avol-V commented Jan 11, 2018

Big Int in Stage 3: https://github.com/tc39/proposal-bigint

@xtuc
Copy link
Author

xtuc commented Jan 11, 2018

Yes I know, but the wording it a bit misleading IMO. I think that int64 or uint64 should be denoted as bigint.

@sirisian
Copy link
Owner

The goal with this proposal would be to implement all the types natively that don't exist. So if the proposal was included then int64 and uint64 would be representable. (There's a note in the spec changes about this here: https://github.com/sirisian/ecmascript-types#11831-static-semantics-mvs). You could write:

let foo:uint64 = 18446744073709551615;
let bar:uint64 = 0xFFFFFFFFFFFFFFFF;

How a dynamically typed variable would handle such a number is good question though that isn't covered yet in the proposal. So if you call foo(0xFFFFFFFFFFFFFFFF) what happens? It's clearly not a number. I would be inclined to say that it automatically uses uint64 transparently, but others might suggest that it throws a TypeError and requires explicit typing for such constants.

@xtuc
Copy link
Author

xtuc commented Jan 11, 2018

Note that currently the spec says: 2 ** 53 + 1 === 2 ** 53, I don't think we could implement the int64 easily and the bigInt proposal requires an explicit conversion.

@sirisian
Copy link
Owner

sirisian commented Jan 12, 2018

I'm trying to design things such that literal suffixes aren't necessary. As an example I'd like this to work:

let foo:uint64 = 9007199254740993 + 9007199254740992; // 18014398509481985

The last thing I'd want is to have to do:

let foo:uint64 = uint64(9007199254740993) + uint64(9007199254740992); // 18014398509481985

If the language is setup in a way that it's forced to be let foo:uint64 = Number + Number; with no workaround that would be annoying. That might not be something that can be avoided though.

let foo = 9007199254740993 + 9007199254740992; // 18014398509481984

I'm sure in the AST special rules could be designed to propagate type information to untyped literals. If this can be done to solve all the edge cases I'm unsure, but I'm thinking it could be.

@sirisian
Copy link
Owner

https://github.com/sirisian/ecmascript-types#expanding-representable-numbers

I added a section to maybe prompt more discussion. I have no idea if what I wrote is possible.

@sirisian
Copy link
Owner

Fixed in: https://github.com/sirisian/ecmascript-types#type-propagation-to-literals

I talked with someone more familiar with this, and it's possible. By propagating type information to literals (and arrays) it makes it so that literals are only treated as Number if they have any or Number type applied to them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants