Modulo Operator %%
Isiah Meadows
isiahmeadows at gmail.com
Sat Aug 17 19:53:56 UTC 2019
BTW, that very example is something I cover in my proposal's
introduction. It's also part of why I want an operator - this is one
of the few times where spreading FUD *is* a good idea IMHO.
https://github.com/isiahmeadows/proposal-divisor-dependent-modulo/
-----
Isiah Meadows
contact at isiahmeadows.com
www.isiahmeadows.com
On Fri, Aug 16, 2019 at 12:33 PM Alex Gordon <alextgordon at gmail.com> wrote:
>
> Code that uses % is often surprisingly buggy. For example even a simple function such as this is broken if n is negative:
>
> function isOdd(n) {
> return n % 2 === 1;
> }
>
> isOdd(-3) // false
>
> The same is not true in other programming languages. The same in Python works just fine:
>
> def isOdd(n):
> return n % 2 == 1
>
> isOdd(-3) // true
>
> The advantage of an operator over a function is that it allows us to say to people who are new to JS: "Always use %% instead of % unless you have a good reason". Just the same as we say "Always use === instead of == unless you have a good reason".
>
>
> On Thu, Aug 15, 2019 at 10:01 PM Isiah Meadows <isiahmeadows at gmail.com> wrote:
>>
>> 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
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
More information about the es-discuss
mailing list