allow BigInt?

[determin1st]

There is a new primitive type implemented in Chrome browser (also in Node.js):
https://developers.google.com/web/updates/2018/05/bigint

so, when i compile

a = 123n

the result is

var a;
a = 123;

should this truncation be disabled or fixed? why does it exist in LiveScript? to avoid mis-typings?

[vendethiel]

We allow any suffix, i.e. 126_euros

[rhendric]

It's a little clunky, but there's always a = ``123n``.

[sphvn]

Also a change like this wouldn't be backwards compatible for all use cases such as 12_euros, 23cm & 560m etc.

[determin1st]

i still dont get, why this numeric literal parse mechanism exist
for example:

a = 0xFFFFn # BigInt vs surprise
b = 0123 # 83 vs compile error
c = 0b01111111100000000000000000000000 # 2139095040 vs truncated
d = 1_euro # syntax error vs truncated

doesn't work like it's intended for JS. if it's not bound to anything, maybe it could be cut safely from livescript compiler, why not? let the engine do the work. what back-compatibility are you referencing?

[rhendric]

It exists as a terser, easier-to-read way to add comments to code that uses a lot of numeric constants. For example:

seconds-in-day = 60 /* secs per min */ * 60 /* mins per hr */ * 24 /* hrs */
# or...
seconds-in-day = 60secs_per_min * 60mins_per_hr * 24hrs

Given that this feature exists, removing it could break code that has been using it.

[determin1st]

oh my.. this is not functional at all, not real..

i vote with both hands to drop it in version 2.0! so those who made such comments will not be affected until decide to make compiler upgrade.

[rhendric]

It doesn't seem any less real to me than any other form of comment in code. Either way, you have characters that the machine ignores but that humans reading the code will find helpful in explaining what's going on. It's just another option available to the programmer for documenting their thoughts, in a less obtrusive way than more general comment syntaxes.

[determin1st]

the machine doesnt ignore those characters, for now it's 123n, but earlier it was 0b001 or 0123, as i showed in the example. the one, who ignores/truncates it is the compiler, so they never reach the machine. there are multiple ways to make comments and there should be a good reasoning about why one more method is required/appropriate.

this is a big limitation to primitives and a design mistake, imo. you will never be able to run ahead of engines interpreting native/raw values/literals. it happend in LESS compiler, when css variables appeared, as it tries to interpret any color function, it has to be written like ~'primitive', it's not convenient/better for human who follows engine/underlying language docs, it's worse.

the compromise solution could be some special suffix like _someComment

[rhendric]

The medley of 0x, 0b, octal prefix 0, and suffix n is not exactly an inspiring, future-safe design for literal syntax, and one of LiveScript's (and its predecessors') goals is to paper over such historical bodges with a cleaner syntax. The first three were replaced in LiveScript with the general radix notation (16~FFFF, for example). BigInt is a new kind of thing for JavaScript, and in my opinion merits being thought about on its own terms.

The question you're implicitly raising seems to be whether there will be more BigInt-like ‘modes’ to number literals that get supported by JavaScript engines, and whether the popularity of such modes will be greater than the popularity of number comments in LiveScript, such that the latter should move out of the way to clear syntax space for the former. If not, there are possibly other ways we could notate BigInt-ness (and for now, as I said, ``123n`` will always work). But I think if JavaScript ended up taking a hard turn in the direction of C, and started differentiating such beasts as floats, doubles, and small ints, then reintroducing suffixes could make sense. I don't know how likely that is.

Most of the value of number comments could probably be preserved by requiring that they start with an underscore, I'll grant you that. So in a hypothetical release where we wanted to make some larger breaking changes, that's a compromise I'd consider, if there's no better way to notate BigInts for LiveScript. I'm not yet convinced that there isn't, though.

[vendethiel]

n~123 currently binds the 123 method of n.

[determin1st]

Okay, i got your point. Think about the benefits - no need to write more docs and more code to support/wrap new features. Maybe it's not inspiring, future-safe or well designed things, but the first responsibility lays on JS makers.