Allow specify numbers with suffixes

Andrey Muzalevsky face2world at gmail.com
Mon Dec 18 15:27:11 UTC 2017


> Jerry Schulteis: Unless I badly misunderstood Andrey's post he does not
want something like numeric separators, that get ignored by the VM; he
wants 1M to translate (I presume at compile time) to 1_000_000 (here's
hoping numeric separators makes it into the spec) and 3min to translate to
18_000.

You are correct.

-------------------------------------------------------------

Intresting that cpp implements user literals as operators
http://en.cppreference.com/w/cpp/language/user_literal

I stuck with the idea that number "notation" and number
"literals/postpositions" are the different things...

So basicly if it is possible to say than number
"literal/postposition"("user literal" or "user postposition" or whatever)
SHOULD BE separated from the number by space - it resolves questions
and allows to write e.g.:

    1 min
    1 sec
    1n min
    1uL whatever

Moreover this also may work (it doesn't look good for me, but why not...):

    let minutesLeft = 5;
    let minutesLeftInMs = minutesLeft min; // or (minutesLeft)min

This case preserves number suffix for number types and other goals
and adding kind of generic syntax for "literals/postpositions" (which
basicly are not required to be used with numbers, or return numbers)

So the "literal/postposition" definition is just a simple function with
single argument, which works with any type, e.g.

    function __literal_min(x) {
          // or __postposition_min
        return x * 60 * 1000;
    }


Best regards,

Andrey

2017-12-14 0:36 GMT+02:00 Jerry Schulteis <jdschulteis at yahoo.com>:

> Unless I badly misunderstood Andrey's post he does not want something like
> numeric separators, that get ignored by the VM; he wants 1M to translate (I
> presume at compile time) to 1_000_000 (here's hoping numeric separators
> makes it into the spec) and 3min to translate to 18_000.
>
> While I see some merit to the idea, I think adding such things to the
> language ad hoc leads to PHP--not the direction I'd like to see JavaScript
> take. I think any proposed addition to a language should be reviewed as to
> whether it constitutes a specific case of some more general principle.
>
> Moreover, the BigInt proposal is at Stage 3 and would use an "n" suffix to
> indicate a BigInt literal; the Extensible Numeric Literals proposal is at
> Stage 1 and would make further use of the same syntactic space ("i" for
> imaginary numbers, "m" for decimals); Brendan Eich's Int64 slide deck (
> https://www.slideshare.net/BrendanEich/int64) uses "L" as suffix for
> Int64, "uL" for Uint64, and considers extending the concept to user-defined
> value types. If such user-defined value types ever make it into JavaScript,
> it might give Andrey something close to what he wants.
>
>
> On Tuesday, December 12, 2017, 1:16:02 PM CST, 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 ....
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20171218/b8fd0195/attachment.html>


More information about the es-discuss mailing list