Allow specify numbers with suffixes

Sam Goto goto at chromium.org
Tue Dec 12 19:13:18 UTC 2017


Ha, that's quite interesting.

Somewhat related to the proposal of
https://github.com/tc39/proposal-numeric-separator that we moved forward
earlier this year.

Are you thinking that the suffixes are purely ignored by VMs or that the
conversation is effectively done? That is, is "populationSize = 1M"
equivalent to "populationSize = 1" or does it make a translation somewhere
to "populationSize = 1_000_000"?



On Sun, Nov 26, 2017 at 8:27 AM, Andrey Muzalevsky <face2world at gmail.com>
wrote:

> Thank for your answers
>
> Jerry, I think that in tagged template literals form it won't be widely
> used
>  e.g. `setTimeout(foo, millis`30s`);` is much harder to read than `setTimeout(foo,
> 30000);`
>
> -------
>
> Regarding https://github.com/littledan/proposal-extensible-n
> umeric-literals:
>
> Doesn't conflict with this idea.
>
> Also looks great at first sight. BTW - In my personal opinion - in most
> cases number suffixes/literals/syntaxes are just sugar, and must be
> processed at compile-time (0xFF000000 syntax is also just sugar).
> Also to make this proposal useful - JS also need to support operators
> overloading, without operator overloading do something useful while writing
> `10px + 1em` is impossible, so it decreases usability of this innovation to
> just another way of calling function(for now).
>
> So in my _personal_ opinion, for now it is better to stay with fixed list
> of built-in compile-time executed number suffixes/literals
>
> -------
>
> Regarding https://github.com/tc39/proposal-bigint
>
> The only problem between proposals is the suffix `n` which specifies
> 10^-9. Few thoughts:
>  - milli, nano, etc. suffixes won't be widely used
>  - they always can be replaced with expotential notation 1e-3, 1e-6, ...
>
> So they are removed from this idea,
> Also removed full form, as it doesn't look semantically valid
>
> Updated list of sugar suffixes:
>  - Usable list analogues of 1e3, 1e6, 1e9:
>      - 1K = 1000 = 1e3
>      - 1M = 1000*1000 = 1e6
>      - 1G = 1000*1000*1000 = 1e9
>      - ... (T,P,E,Z,Y)
>  - The same with bytes, nobody will count nanobytes... Isn't it? Usable
> list:
>      - 1KB = 1024
>      - 1MB = 1024*1024
>      - 1GB = 1024*1024*1024
>      - ... (TB,PB,EB,ZB,YB)
>  - Updated time group, this can make life easier for each novice...
>      - 1s = 1000
>      - 1m = 60s
>      - 1h = 60m
>      - 1d = 24h
>      - 1w = 7d
>
> How it looks for you with updates?
>
> Best regards,
>
> Andrey
>
> 2017-11-25 1:22 GMT+02:00 Jerry Schulteis <jdschulteis at yahoo.com>:
>
>> I see the BigInt proposal at the moment uses a suffix 'n' for BigInt
>> literals.
>> That would conflict with Andrey's desire to have it mean metric nano (*
>> 10**-9).
>> Maybe tagged template literals would do?
>>     populationSize = SI`100M`;
>>     setTimeout(foo, millis`30s`);
>>
>> On Thursday, November 23, 2017, 7:22:41 AM CST, Isiah Meadows <
>> isiahmeadows at gmail.com> wrote:
>>
>>
>> Check out the various unit-related proposals that have spawned on this
>> list, and note that IIRC the BigInt proposal [1] also notes that as a
>> possible future expansion.
>>
>> [1]: https://github.com/tc39/proposal-bigint
>>
>> On Thu, Nov 23, 2017, 08:17 Andrey Muzalevsky <face2world at gmail.com>
>> wrote:
>>
>> Idea is simple, also is simple to implement and do not conflicting with
>> existing standard
>>
>> Readability of javascript can be improved in certain cases like:
>>
>>    - populationSize = 100000000
>>    - maxMessageSize = 4194304
>>    - setTimeout(foo, 30000)
>>    - if(timeElapsed > 100) {...}
>>
>> This can be changed to following:
>>
>>    - populationSize = 100M
>>    - maxMessageSize = 4MB
>>    - setTimeout(foo, 30s)
>>    - if(timeElapsed > 0.1s) {...}
>>
>> Also it will be great to support floating number, most convinient way to
>> do this is tract suffix just like a multipler, so
>>
>> 1.5MB == 1.5 * 1MB
>>
>> Supported suffixes, as I see them:
>>
>>    - Metric prefixes group
>>       - follow SI Prefixes
>>       <http://www.npl.co.uk/reference/measurement-units/si-prefixes/>
>>       scheme, to decrease entrance level
>>       - allowing to use short and full form
>>       - it is case sensetive (bad, but everyone knows it)
>>       - not sure about μ, it either:
>>       - (my preference) supported as UTF-8 sumbol, always can be
>>          replaced with 'full' form when needed(is it recommended to use?)
>>          - has a replace symbol which can be easily typed
>>          - allowed only in full form
>>       - samples:
>>          - 4M == 4mega == 4 000 000
>>          - 5n == 5nano == 0.000 000 005
>>          - 1micro == 0.000 001
>>       - Bytes prefixes group
>>       - Metric prefixes turned into bytes prefixes by adding either 'B'
>>       to short form, or 'byte[s]' to full form
>>       - Byte suffix is written in upper-case 'B', e.g. 'kB', 'MB', 'GB'
>>          - This is done to remove inconsistency with widely used
>>          bit/byte differentiation, e.g. `kb` and `KB` usually mean different things
>>       - Samples:
>>          - 1kB = 1kilobyte = 1024
>>          - 1MB = 1megabyte = 1024*1024
>>       - Time group, counted in milliseconds
>>    - s, sec = 1000
>>       - min = 60 * 1000
>>       - h, hr = 60 * 60 * 1000
>>       - d, day[s] = 24 * 60 * 60 * 1000
>>       - w, week[s] = 7 * 24 * 60 * 60 * 1000
>>    - Also it will be good to allow compound number definitions, samples
>>    - 1h 30min = 1h + 30min
>>       - 1mB 200kB = 1mB + 200kB
>>
>>
>> What do you think?
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20171212/521bb8f4/attachment-0001.html>


More information about the es-discuss mailing list