> On Dec 13, 2017, at 2:15 AM, Sam Goto <[email protected]> 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>>: > 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 > <[email protected] <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> 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 > [email protected] <mailto:[email protected]> > https://mail.mozilla.org/listinfo/es-discuss > <https://mail.mozilla.org/listinfo/es-discuss> > _______________________________________________ > es-discuss mailing list > [email protected] <mailto:[email protected]> > https://mail.mozilla.org/listinfo/es-discuss > <https://mail.mozilla.org/listinfo/es-discuss> > > > _______________________________________________ > es-discuss mailing list > [email protected] <mailto:[email protected]> > https://mail.mozilla.org/listinfo/es-discuss > <https://mail.mozilla.org/listinfo/es-discuss> > > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
