Allow specify numbers with suffixes

J Decker d3ck0r at gmail.com
Wed Dec 13 01:26:00 UTC 2017


On Tue, Dec 12, 2017 at 1:24 PM, kai zhu <kaizhu256 at gmail.com> wrote:

>
> 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.
>
>
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 <goto at chromium.org> 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 <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
>>>
>>>
>>
> _______________________________________________
> 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/f4457838/attachment-0001.html>


More information about the es-discuss mailing list