+ 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 <g...@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 <face2wo...@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 <jdschult...@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 < >>> isiahmead...@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 <face2wo...@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@mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> _______________________________________________ >>> es-discuss mailing list >>> es-discuss@mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
