
12

JS needs a modulo operator. It currently has the remainder operator `%` which works in most cases except for negative values. I believe the the `%%` would work great and be easy to remember.
let x = (13) %% 64; is equivalent to let x = ((13 % 64) + 64) % 64;
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


I would welcome such an operator as well. I find myself implementing a `mod`
function from time to time, expressing it in terms of the remainder operator.
As for syntax, I don't see `%%` posing any syntactical ambiguities, so I'll
second it.
On Monday, August 12, 2019 10:00:09 PM CEST Matthew Morgan wrote:
> JS needs a modulo operator. It currently has the remainder operator `%`
> which works in most cases except for negative values. I believe the the
> `%%` would work great and be easy to remember.
>
> let x = (13) %% 64;
> is equivalent to
> let x = ((13 % 64) + 64) % 64; _______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


agreed, let's make a proposal I would welcome such an operator as well. I find myself implementing a `mod`
function from time to time, expressing it in terms of the remainder operator.
As for syntax, I don't see `%%` posing any syntactical ambiguities, so I'll
second it.
On Monday, August 12, 2019 10:00:09 PM CEST Matthew Morgan wrote:
> JS needs a modulo operator. It currently has the remainder operator `%`
> which works in most cases except for negative values. I believe the the
> `%%` would work great and be easy to remember.
>
> let x = (13) %% 64;
> is equivalent to
> let x = ((13 % 64) + 64) % 64;_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


Related:
https://esdiscuss.org/notes/20180124#13vdoperatoroverloadingforstage1
I don’t see anything newer than this
From: esdiscuss <[hidden email]>
On Behalf Of Cyril Auburtin
Sent: Tuesday, August 13, 2019 5:07 AM
Cc: esdiscuss <[hidden email]>
Subject: Re: Modulo Operator %%
agreed, let's make a proposal
I would welcome such an operator as well. I find myself implementing a `mod`
function from time to time, expressing it in terms of the remainder operator.
As for syntax, I don't see `%%` posing any syntactical ambiguities, so I'll
second it.
On Monday, August 12, 2019 10:00:09 PM CEST Matthew Morgan wrote:
> JS needs a modulo operator. It currently has the remainder operator `%`
> which works in most cases except for negative values. I believe the the
> `%%` would work great and be easy to remember.
>
> let x = (13) %% 64;
> is equivalent to
> let x = ((13 % 64) + 64) % 64;_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


On 8/13/19 7:27 AM, Michael Haufe wrote:
> I would prefer the syntax be ‘a mod b’ consistent with my wishlist item:
This can bring up various syntactic troubles. What does the following do?
let mod
+3
Is it calling the mod operator on the variable named "let" and +3? Or is it defining a variable named "mod" with no initializer, followed by an expression?
Waldemar
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


On 8/13/19 7:27 AM, Michael Haufe wrote:
> I would prefer the syntax be ‘a mod b’ consistent with my wishlist item:
On 8/13/19 9:12 PM, Waldemar Horwat wrote:
> This can bring up various syntactic troubles. What does the following do?
>
> let mod
> +3
>
> Is it calling the mod operator on the variable named "let" and +3? Or is it defining a variable named "mod" with no initializer, followed by an expression?
I can't declare 'let' or 'var' as variable names, but even if I could (Say nonstrict mode or ES3) that form would be a VariableDeclaration followed by an ExpressionStatement.
The proposed grammar extension is:
MultiplicativeOperator: one of
* / % div mod
Michael
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


For syntactic precedent, CoffeeScript and R both have `%%` for a
modulus returning the sign of the divisor, where `a %% b` is
equivalent to `(a % b + b) % b`. So JS wouldn't be the first here.
Most languages Wikipedia lists in their comparison
( https://en.wikipedia.org/wiki/Modulo_operation) use a function for
this kind of modulus operation, not an operator. That itself seems
worth noting.

Isiah Meadows
[hidden email]
www.isiahmeadows.com
On Tue, Aug 13, 2019 at 10:27 AM Michael Haufe < [hidden email]> wrote:
>
> I would prefer the syntax be ‘a mod b’ consistent with my wishlist item:
>
>
>
> < https://esdiscuss.org/topic/newoperator>
>
> < https://esdiscuss.org/topic/stillwaitingforintegerdivision>
>
>
>
> In regards to semantics:
>
>
>
> < https://www.microsoft.com/enus/research/wpcontent/uploads/2016/02/divmodnote.pdf>
>
>
>
>
>
>
>
> From: esdiscuss < [hidden email]> On Behalf Of Cyril Auburtin
> Sent: Tuesday, August 13, 2019 5:07 AM
> Cc: esdiscuss < [hidden email]>
> Subject: Re: Modulo Operator %%
>
>
>
> agreed, let's make a proposal
>
>
>
> On Tue, Aug 13, 2019 at 12:06 AM kdex < [hidden email]> wrote:
>
> I would welcome such an operator as well. I find myself implementing a `mod`
> function from time to time, expressing it in terms of the remainder operator.
>
> As for syntax, I don't see `%%` posing any syntactical ambiguities, so I'll
> second it.
>
> On Monday, August 12, 2019 10:00:09 PM CEST Matthew Morgan wrote:
> > JS needs a modulo operator. It currently has the remainder operator `%`
> > which works in most cases except for negative values. I believe the the
> > `%%` would work great and be easy to remember.
> >
> > let x = (13) %% 64;
> > is equivalent to
> > let x = ((13 % 64) + 64) % 64;_______________________________________________
> esdiscuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/esdiscuss>
> _______________________________________________
> esdiscuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/esdiscuss_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


On 8/13/19 8:32 PM, Michael Haufe wrote:
> On 8/13/19 7:27 AM, Michael Haufe wrote:
>> I would prefer the syntax be ‘a mod b’ consistent with my wishlist item:
>
> On 8/13/19 9:12 PM, Waldemar Horwat wrote:
>> This can bring up various syntactic troubles. What does the following do?
>>
>> let mod
>> +3
>>
>> Is it calling the mod operator on the variable named "let" and +3? Or is it defining a variable named "mod" with no initializer, followed by an expression?
>
> I can't declare 'let' or 'var' as variable names, but even if I could (Say nonstrict mode or ES3) that form would be a VariableDeclaration followed by an ExpressionStatement.
>
> The proposed grammar extension is:
>
> MultiplicativeOperator: one of
> * / % div mod
And I'm saying that's potentially problematic because it changes the meaning of existing programs that happen to use "mod" as a variable name. The above is one example that would turn a let statement into a mod expression. Here's another example:
x = 4
mod(foo)
Waldemar
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


JS needs a modulo operator. It currently has the remainder operator `%` which works in most cases except for negative values. I believe the the `%%` would work great and be easy to remember.
let x = (13) %% 64; is equivalent to let x = ((13 % 64) + 64) % 64;
Is there a strong advantage of an `%%` operator over a `Math.mod()` function? There is the precedent of the `**` operator implemented as alternative of `Math.pow()` few years ago. It would be interesting to hear the feedback of those that use regularly powers, whether the benefit was clear (personally, I almost never use either `Math.pow()` or `**`, so that I can’t say anything).
At least one disadvantage of an operator over a function, is that you have to think about precedence. The problem is exacerbated in JS, because (following some other languages) the unary minus has an uncanny high precedence level, confusingly very different than the one of the binary minus; so that, after having designed `**`, it was realised at the last minute that `a**b` would be dumbly interpreted as `(a)**b` instead of `(a**b)` or `0a**b`, as anybody who would be likely to actually use the operator would expect. (That particular issue was resolved in a hurry by making the parenthesisleft form a syntax error.)
—Claude
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


FWIW another disadvantage is that operators cannot be polyfilled, so it'll take forever for those not using transpilers to adopt these, while having a `Math,mod` would work right away
JS needs a modulo operator. It currently has the remainder operator `%` which works in most cases except for negative values. I believe the the `%%` would work great and be easy to remember.
let x = (13) %% 64; is equivalent to let x = ((13 % 64) + 64) % 64;
Is there a strong advantage of an `%%` operator over a `Math.mod()` function? There is the precedent of the `**` operator implemented as alternative of `Math.pow()` few years ago. It would be interesting to hear the feedback of those that use regularly powers, whether the benefit was clear (personally, I almost never use either `Math.pow()` or `**`, so that I can’t say anything).
At least one disadvantage of an operator over a function, is that you have to think about precedence. The problem is exacerbated in JS, because (following some other languages) the unary minus has an uncanny high precedence level, confusingly very different than the one of the binary minus; so that, after having designed `**`, it was realised at the last minute that `a**b` would be dumbly interpreted as `(a)**b` instead of `(a**b)` or `0a**b`, as anybody who would be likely to actually use the operator would expect. (That particular issue was resolved in a hurry by making the parenthesisleft form a syntax error.)
—Claude
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


Is there any way we can add function/operator equivalence to the language? Perhaps some kind of 'operators' global object with symbol fields matching operator string to functions/constraints?  Dammit babies, you've got to be kind. On Thu, 15 Aug 2019 at 08:47, Andrea Giammarchi < [hidden email]> wrote: FWIW another disadvantage is that operators cannot be polyfilled, so it'll take forever for those not using transpilers to adopt these, while having a `Math,mod` would work right away
JS needs a modulo operator. It currently has the remainder operator `%` which works in most cases except for negative values. I believe the the `%%` would work great and be easy to remember.
let x = (13) %% 64; is equivalent to let x = ((13 % 64) + 64) % 64;
Is there a strong advantage of an `%%` operator over a `Math.mod()` function? There is the precedent of the `**` operator implemented as alternative of `Math.pow()` few years ago. It would be interesting to hear the feedback of those that use regularly powers, whether the benefit was clear (personally, I almost never use either `Math.pow()` or `**`, so that I can’t say anything).
At least one disadvantage of an operator over a function, is that you have to think about precedence. The problem is exacerbated in JS, because (following some other languages) the unary minus has an uncanny high precedence level, confusingly very different than the one of the binary minus; so that, after having designed `**`, it was realised at the last minute that `a**b` would be dumbly interpreted as `(a)**b` instead of `(a**b)` or `0a**b`, as anybody who would be likely to actually use the operator would expect. (That particular issue was resolved in a hurry by making the parenthesisleft form a syntax error.)
—Claude
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


We could circumvent this by making `%%` analogous to `**`. That is, we could
provide a function form `Math.mod` as well as an infix operator `%%`.
On Thursday, August 15, 2019 9:46:57 AM CEST Andrea Giammarchi wrote:
> FWIW another disadvantage is that operators cannot be polyfilled, so it'll
> take forever for those not using transpilers to adopt these, while having a
> `Math,mod` would work right away
>
> On Thu, Aug 15, 2019 at 8:40 AM Claude Pache < [hidden email]> wrote:
> > Le 12 août 2019 à 22:00, Matthew Morgan < [hidden email]> a écrit :
> >
> > JS needs a modulo operator. It currently has the remainder operator `%`
> > which works in most cases except for negative values. I believe the the
> > `%%` would work great and be easy to remember.
> >
> > let x = (13) %% 64;
> > is equivalent to
> > let x = ((13 % 64) + 64) % 64;
> >
> >
> > Is there a strong advantage of an `%%` operator over a `Math.mod()`
> > function? There is the precedent of the `**` operator implemented as
> > alternative of `Math.pow()` few years ago. It would be interesting to hear
> > the feedback of those that use regularly powers, whether the benefit was
> > clear (personally, I almost never use either `Math.pow()` or `**`, so that
> > I can’t say anything).
> >
> > At least one disadvantage of an operator over a function, is that you have
> > to think about precedence. The problem is exacerbated in JS, because
> > (following some other languages) the unary minus has an uncanny high
> > precedence level, confusingly very different than the one of the binary
> > minus; so that, after having designed `**`, it was realised at the last
> > minute that `a**b` would be dumbly interpreted as `(a)**b` instead of
> > `(a**b)` or `0a**b`, as anybody who would be likely to actually use the
> > operator would expect. (That particular issue was resolved in a hurry by
> > making the parenthesisleft form a syntax error.)
> >
> > —Claude
> >
> > _______________________________________________
> > esdiscuss mailing list
> > [hidden email]
> > https://mail.mozilla.org/listinfo/esdiscuss_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


On 8/14/19 7:50 PM, Waldemar Horwat wrote:
> And I'm saying that's potentially problematic because it changes the meaning of existing programs that happen to use "mod" as a variable name. The above is one example that would turn a let statement into a mod expression. Here's another example:
>
> x = 4
> mod(foo)
Potentially yes and surely there is a yacc definition where one could check to be certain? Regardless, let's assume there is or that workarounds to guarantee infixity are not worth the complication ([no LineTerminator here] usage).
We know that syntax is the last bastion of language luddites, so it's best not to linger on something which was not my main concern. I am more interested in maintaining the duality of the operators over how they are represented (within reason). Thus, if '%%' is what is preferable, then '\\' would be the partner.
Michael
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


An operator is far more concise than a function call, and is likely to
see greater use. It also aligns better with peoples' intuition on what
the "modulus" is, avoiding subtle bugs like in `isOdd = x => x % 2 ===
1` (example from
https://en.wikipedia.org/wiki/Modulo_operation#Common_pitfalls  try
passing a negative to it). And given this one is high value (see
above) and *very* low cost (it can literally desugar to `(x % y + y) %
y`), I feel it does meet that bar.
> It would be interesting to hear the feedback of those that use regularly powers, whether the benefit was clear (personally, I almost never use either `Math.pow()` or `**`, so that I can’t say anything).
It has enough benefit I've seen CoffeeScript users default to `%%` and
only using `%` when they explicitly want the dividenddependent
semantics. And engines with a native `%%`, if they can detect the
operands are always nonnegative, can optimize it to `%` pretty
easily. It's better *enough* that you'd likely start seeing some
partially legitimate FUD spread about the standard `%`.
One other added benefit of using divisordependent modulo is that `x
%% (2**n)`, where `x` and `n` are integers and `n >= 0`, could always
be safely rewritten to `x & (2**n  1)` while still preserving
semantics, but `x % (2**n)` does *not* have this property. For
example:
 `1 %% (2**1)` → `1 %% 1` → `1`
 `1 & (2**1  1)` → `1 & 1` → `1`
 `1 % (2**1)` → `1 % 2` → `1`
BTW, I literally tested all three of these in Chrome's devtools
console, using my `x %% y` → `(x % y + y) % y` desugaring.
As for a native implementation and the spec, I'd recommend just doing
`copysign(fmod(x, y), y)` instead to retain precision.
> At least one disadvantage of an operator over a function, is that you have to think about precedence. The problem is exacerbated in JS, because (following some other languages) the unary minus has an uncanny high precedence level, confusingly very different than the one of the binary minus; so that, after having designed `**`, it was realised at the last minute that `a**b` would be dumbly interpreted as `(a)**b` instead of `(a**b)` or `0a**b`, as anybody who would be likely to actually use the operator would expect. (That particular issue was resolved in a hurry by making the parenthesisleft form a syntax error.)
I doubt this would happen with `%%`. It's similar enough to the
existing `%` in concept that most would expect it to have the same
precedence. With `**`, there was a very unique issue with it: there
were people actually *reading* it both ways, and even a language
(Python) that interprets `a ** b` and `a**b` *differently* in light
of that (as `(a) ** b` and `(a ** b)` respectively). That's not a
concern at all with most operators, so it doesn't apply to most new
operator proposals.

Isiah Meadows
[hidden email]
www.isiahmeadows.com
On Thu, Aug 15, 2019 at 2:40 AM Claude Pache < [hidden email]> wrote:
>
>
>
> Le 12 août 2019 à 22:00, Matthew Morgan < [hidden email]> a écrit :
>
> > JS needs a modulo operator. It currently has the remainder operator `%` which works in most cases except for negative values. I believe the the `%%` would work great and be easy to remember.
> >
> > let x = (13) %% 64;
> > is equivalent to
> > let x = ((13 % 64) + 64) % 64;
>
>
> Is there a strong advantage of an `%%` operator over a `Math.mod()` function? There is the precedent of the `**` operator implemented as alternative of `Math.pow()` few years ago. It would be interesting to hear the feedback of those that use regularly powers, whether the benefit was clear (personally, I almost never use either `Math.pow()` or `**`, so that I can’t say anything).
>
> At least one disadvantage of an operator over a function, is that you have to think about precedence. The problem is exacerbated in JS, because (following some other languages) the unary minus has an uncanny high precedence level, confusingly very different than the one of the binary minus; so that, after having designed `**`, it was realised at the last minute that `a**b` would be dumbly interpreted as `(a)**b` instead of `(a**b)` or `0a**b`, as anybody who would be likely to actually use the operator would expect. (That particular issue was resolved in a hurry by making the parenthesisleft form a syntax error.)
>
> —Claude
>
> _______________________________________________
> esdiscuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/esdiscuss_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


To me there's no risk, as MooTools, Prototype, and Scriptacolous are both things of the past, and never implemented Math.mod ... so, with that approach, custom transpiling functions are more dangerous, as somebody might have implemented `%%` already for other purposes, and we break Babel outcome adding new syntax anyway ... the smoosh accident, is the equivalent of custom Babel utilities these days.
Look at TypeScript and the private class fields, if you want to compare new syntax instead
Thursday, August 15, 2019 2:47 AM, Andrea Giammarchi wrote:
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


Fair points, but since `**` has its `Math.pow` counter part, why wouldn't `%%` have `Math.mod` as counterpart too? At least it looks like there's room for both, if standardized, as the behavior and description would likely be mostly the same (precedence a part)
An operator is far more concise than a function call, and is likely to
see greater use. It also aligns better with peoples' intuition on what
the "modulus" is, avoiding subtle bugs like in `isOdd = x => x % 2 ===
1` (example from
https://en.wikipedia.org/wiki/Modulo_operation#Common_pitfalls  try
passing a negative to it). And given this one is high value (see
above) and *very* low cost (it can literally desugar to `(x % y + y) %
y`), I feel it does meet that bar.
> It would be interesting to hear the feedback of those that use regularly powers, whether the benefit was clear (personally, I almost never use either `Math.pow()` or `**`, so that I can’t say anything).
It has enough benefit I've seen CoffeeScript users default to `%%` and
only using `%` when they explicitly want the dividenddependent
semantics. And engines with a native `%%`, if they can detect the
operands are always nonnegative, can optimize it to `%` pretty
easily. It's better *enough* that you'd likely start seeing some
partially legitimate FUD spread about the standard `%`.
One other added benefit of using divisordependent modulo is that `x
%% (2**n)`, where `x` and `n` are integers and `n >= 0`, could always
be safely rewritten to `x & (2**n  1)` while still preserving
semantics, but `x % (2**n)` does *not* have this property. For
example:
 `1 %% (2**1)` → `1 %% 1` → `1`
 `1 & (2**1  1)` → `1 & 1` → `1`
 `1 % (2**1)` → `1 % 2` → `1`
BTW, I literally tested all three of these in Chrome's devtools
console, using my `x %% y` → `(x % y + y) % y` desugaring.
As for a native implementation and the spec, I'd recommend just doing
`copysign(fmod(x, y), y)` instead to retain precision.
> At least one disadvantage of an operator over a function, is that you have to think about precedence. The problem is exacerbated in JS, because (following some other languages) the unary minus has an uncanny high precedence level, confusingly very different than the one of the binary minus; so that, after having designed `**`, it was realised at the last minute that `a**b` would be dumbly interpreted as `(a)**b` instead of `(a**b)` or `0a**b`, as anybody who would be likely to actually use the operator would expect. (That particular issue was resolved in a hurry by making the parenthesisleft form a syntax error.)
I doubt this would happen with `%%`. It's similar enough to the
existing `%` in concept that most would expect it to have the same
precedence. With `**`, there was a very unique issue with it: there
were people actually *reading* it both ways, and even a language
(Python) that interprets `a ** b` and `a**b` *differently* in light
of that (as `(a) ** b` and `(a ** b)` respectively). That's not a
concern at all with most operators, so it doesn't apply to most new
operator proposals.

Isiah Meadows
[hidden email]
www.isiahmeadows.com
On Thu, Aug 15, 2019 at 2:40 AM Claude Pache <[hidden email]> wrote:
>
>
>
> Le 12 août 2019 à 22:00, Matthew Morgan <[hidden email]> a écrit :
>
> > JS needs a modulo operator. It currently has the remainder operator `%` which works in most cases except for negative values. I believe the the `%%` would work great and be easy to remember.
> >
> > let x = (13) %% 64;
> > is equivalent to
> > let x = ((13 % 64) + 64) % 64;
>
>
> Is there a strong advantage of an `%%` operator over a `Math.mod()` function? There is the precedent of the `**` operator implemented as alternative of `Math.pow()` few years ago. It would be interesting to hear the feedback of those that use regularly powers, whether the benefit was clear (personally, I almost never use either `Math.pow()` or `**`, so that I can’t say anything).
>
> At least one disadvantage of an operator over a function, is that you have to think about precedence. The problem is exacerbated in JS, because (following some other languages) the unary minus has an uncanny high precedence level, confusingly very different than the one of the binary minus; so that, after having designed `**`, it was realised at the last minute that `a**b` would be dumbly interpreted as `(a)**b` instead of `(a**b)` or `0a**b`, as anybody who would be likely to actually use the operator would expect. (That particular issue was resolved in a hurry by making the parenthesisleft form a syntax error.)
>
> —Claude
>
> _______________________________________________
> esdiscuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/esdiscuss
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


Static functions don't have the same risk as prototype functions; `Math.mod` would make sense to add.
One suggestion, though, would be to try to add the API method first, and look at usage for awhile before trying to add the syntax. On Thu, Aug 15, 2019 at 10:12 AM Andrea Giammarchi < [hidden email]> wrote: To me there's no risk, as MooTools, Prototype, and Scriptacolous are both things of the past, and never implemented Math.mod ... so, with that approach, custom transpiling functions are more dangerous, as somebody might have implemented `%%` already for other purposes, and we break Babel outcome adding new syntax anyway ... the smoosh accident, is the equivalent of custom Babel utilities these days.
Look at TypeScript and the private class fields, if you want to compare new syntax instead
Thursday, August 15, 2019 2:47 AM, Andrea Giammarchi wrote:
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


BTW, I just wrote up a more precise, formalized proposal over here:
https://github.com/isiahmeadows/proposaldivisordependentmodulo/,
and I'd be more than willing to work with a TC39 champion on it. I
personally prefer syntax (pretty strongly), but I'm not beholden to
it.
I do feel the semantics are simple enough it'd be okay to lower it to
syntax, and it naturally just glides right in. I find it *very* odd
that some languages use a simple operator `%` or relatively short
function for remainder keeping the sign of the dividend but relegate
the version keeping the sign of the divisor (the more useful and
intuitive of them) to a much more verbose function call. Of all
Wikipedia lists in https://en.wikipedia.org/wiki/Modulo_operation,
here's the four that do this currently  all but one expose an
operator for the first:
 Fortran: `mod` for dividenddependent, `modulo` for divisordependent
 Julia: `%`/`rem` for dividenddependent, `mod` for divisordependent
 Java: `%` for dividenddependent, `Math.floorMod` for divisordependent
 XBase++: `%` for dividenddependent, `Mod` for divisordependent
And it's worth noting most other languages (including some end
useroriented ones) that show a syntactic preference to one or the
other expose a simpler one where the sign matches the divisor, a more
complicated one where the sign matches the dividend. For a variety of
examples:
 Ruby: `%`/`modulo` for divisordependent, `remainder` for dividenddependent
 SML: `mod` for divisordependent, `Int.rem` for dividenddependent
 Elm: `modBy` for divisordependent, `remainderBy` for dividenddependent
 Euphoria: `mod` for divisordependent, `remainder` for dividenddependent
 Python: `%` for divisordependent, `math.fmod` for dividenddependent
 Smalltalk: `\\` for divisordependent, `rem:` for dividenddependent
And of course, many don't even expose a type of modulo where the sign
matches the divisor. For some examples:
 APL
 LibreOffice/Excel
 Lua
 Perl
 Mathematica
 PL/I
 TCL
There's also Dart, a relatively new language which defaults to
nonnegative always.
This relatively long list of languages, *despite* C's heritage and
semantics being inherited in much of them, makes me question using a
function for this, and there would need to be a *lot* of FUD to get
people to use the function more than the operator.
So this is why I would prefer an operator as opposed to syntax for this.

Isiah Meadows
[hidden email]
www.isiahmeadows.com
On Thu, Aug 15, 2019 at 3:58 PM Jordan Harband < [hidden email]> wrote:
>
> Static functions don't have the same risk as prototype functions; `Math.mod` would make sense to add.
>
> One suggestion, though, would be to try to add the API method first, and look at usage for awhile before trying to add the syntax.
>
> On Thu, Aug 15, 2019 at 10:12 AM Andrea Giammarchi < [hidden email]> wrote:
>>
>> To me there's no risk, as MooTools, Prototype, and Scriptacolous are both things of the past, and never implemented Math.mod ... so, with that approach, custom transpiling functions are more dangerous, as somebody might have implemented `%%` already for other purposes, and we break Babel outcome adding new syntax anyway ... the smoosh accident, is the equivalent of custom Babel utilities these days.
>>
>> Look at TypeScript and the private class fields, if you want to compare new syntax instead
>>
>> On Thu, Aug 15, 2019 at 4:50 PM Michael Haufe < [hidden email]> wrote:
>>>
>>> Thursday, August 15, 2019 2:47 AM, Andrea Giammarchi wrote:
>>>
>>>
>>>
>>> > FWIW another disadvantage is that operators cannot be polyfilled, so it'll take forever for those not using transpilers to adopt these, while having a `Math,mod` would work right away
>>>
>>>
>>>
>>>
>>>
>>> With such an approach there is risk of another ‘smooshgate’ [1][2]. There is nothing stopping those developers from using a function anyway to bridge the gap if they can’t or won’t use a compiler. This is already the current state of affairs.
>>>
>>>
>>>
>>> [1] https://developers.google.com/web/updates/2018/03/smooshgate>>>
>>> [2] https://adamsilver.io/articles/thedisadvantagesofjavascriptpolyfills/>>>
>>>
>>>
>>> Michael
>>
>> _______________________________________________
>> esdiscuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/esdiscuss>
> _______________________________________________
> esdiscuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/esdiscuss_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss

12
