Modulo Operator %%

Isiah Meadows isiahmeadows at gmail.com
Thu Aug 15 21:01:24 UTC 2019


BTW, I just wrote up a more precise, formalized proposal over here:
https://github.com/isiahmeadows/proposal-divisor-dependent-modulo/,
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 dividend-dependent, `modulo` for divisor-dependent
- Julia: `%`/`rem` for dividend-dependent, `mod` for divisor-dependent
- Java: `%` for dividend-dependent, `Math.floorMod` for divisor-dependent
- XBase++: `%` for dividend-dependent, `Mod` for divisor-dependent

And it's worth noting most other languages (including some end
user-oriented 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 divisor-dependent, `remainder` for dividend-dependent
- SML: `mod` for divisor-dependent, `Int.rem` for dividend-dependent
- Elm: `modBy` for divisor-dependent, `remainderBy` for dividend-dependent
- Euphoria: `mod` for divisor-dependent, `remainder` for dividend-dependent
- Python: `%` for divisor-dependent, `math.fmod` for dividend-dependent
- Smalltalk: `\\` for divisor-dependent, `rem:` for dividend-dependent

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
non-negative 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
contact at isiahmeadows.com
www.isiahmeadows.com

On Thu, Aug 15, 2019 at 3:58 PM Jordan Harband <ljharb at gmail.com> 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 <andrea.giammarchi at gmail.com> 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 <tno at thenewobjective.com> 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/the-disadvantages-of-javascript-polyfills/
>>>
>>>
>>>
>>> Michael
>>
>> _______________________________________________
>> 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


More information about the es-discuss mailing list