Allow specify numbers with suffixes

kai zhu kaizhu256 at gmail.com
Tue Dec 12 21:24:34 UTC 2017


> On Dec 13, 2017, at 2:15 AM, Sam Goto <goto at chromium.org> wrote:
> 
> + 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 ….

-1
the difference is that numeric-separators are well-defined and hopefully a one-time language-change that never has to be re-visited again.  these proposed numbers-with-suffixes are arbitrary and nobody is naive enough to believe they won’t be revisited repeatedly in the future.  they open a can-of-worms to never-ending future language-feature requests (like destructuring and import-statements did), which harms tooling and language stability.


> On Tue, Dec 12, 2017 at 11:13 AM, Sam Goto <goto at chromium.org <mailto:goto at chromium.org>> wrote:
> Ha, that's quite interesting.
> 
> Somewhat related to the proposal of https://github.com/tc39/proposal-numeric-separator <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 <mailto: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-numeric-literals <https://github.com/littledan/proposal-extensible-numeric-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 <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 <mailto: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 <mailto: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 <https://github.com/tc39/proposal-bigint>
> On Thu, Nov 23, 2017, 08:17 Andrey Muzalevsky <face2world at gmail.com <mailto: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 <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
> 
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss <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/20171213/b21790f9/attachment-0001.html>


More information about the es-discuss mailing list