Allow specify numbers with suffixes

Sam Goto goto at chromium.org
Tue Dec 12 19:15:56 UTC 2017


+ rick that co-authored numeric separators too and may have thoughts on
this. my first impression is that this (if kept purely as something that
gets ignored by the VMs) shares a lot of the sentiments with numeric
separators ....

On Tue, Dec 12, 2017 at 11:13 AM, Sam Goto <goto at chromium.org> wrote:

> 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/cd75fb34/attachment.html>


More information about the es-discuss mailing list