On Tue, Dec 12, 2017 at 1:24 PM, kai zhu <[email protected]> wrote:
> > 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. > > My concern would be the non-symmetry/irreversability of this.... (can't get out what you put in) Factorio uses such suffixes in their mods but that's a total one-off. I've not seen real standards anywhere for this sort of thing in any language generally. B as an additional suffix to say base 2 is actually fairly arbitrary... (although this page suggests such a thiing) http://people.csail.mit.edu/jaffer/MIXF/MIXF-08 says only languages could be extended, but has no examples of any language with support. There's also no NPM for such a thing (if there is it's called something I wouldn't think of) https://www.npmjs.com/package/convert-units (converts a value to another value, and uses such metric suffixes, but only as strings to .from() and .to() ) And these two that convert from a number to text, but not the other way around... https://www.npmjs.com/package/metric-suffix https://www.npmjs.com/package/number-suffix Even math heavy lanauages (mathematica/Wolfram, R, FORTRAN ); human friendly lanaguages (BASIC, COBOL); and kid friendly Scratch, et al. son't have such support. So I think someone should first implement it as a library/package (maybe even going as far as to overload Number()/new Number() when converting numbers... > On Tue, Dec 12, 2017 at 11:13 AM, Sam Goto <[email protected]> wrote: > >> Ha, that's quite interesting. >> >> Somewhat related to the proposal of https://github.com/tc39/pro >> posal-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]> >> 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 <[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]> 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 <[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] >>>> 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 >>> >>> >> > _______________________________________________ > 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 > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
