Re: Language Revision : "/" and "div"

[Gene <gene.ressler@gmail.com>]

On May 1, 2:52 am, "vincent.diemun...@gmail.com"
<vincent.diemun...@gmail.com> wrote:
> Hi everybody,
>
> I wonder why Ada uses "/" to express the integer division and not
> "div".
> This leads to the fact that an expression like 4/3*6 that any decent
> calculator
> would evaluate as 8 is in Ada evaluated as 6 !!! That is a shame :-).
>
> Therefore, I propose the following, for a new revision of the
> language :
> - discard the function "/" (left, right : Integer) return Integer and
> replace it by the operator "div",
> that sounds quite logical with the existing "rem" and "mod".
> - add a fraction package with a function "/" (left, right :
> Integer'base) return Fraction; as constructor.
>
> Then when compiling "n : integer := 4/3*6;" an error will occur,
> because the result will be the fraction
> 8/1 and not an integer. The sentence could then be changed in
> EITHER "n : integer := (4 div 3)*6" that explicitly states that the
> result will be 6.
> OR        "n : integer := Rounding (4/3*6);
>
> I think this solution is safe and will add simplicity and precision to
> integer operations.
> Moreover, this correct handling of integer computation will allow
> compilers to make optimizations
> like for instance simplifying expressions like "2/3 * n * 6 * i" ->
> "4*n*i"
>
> Do you think I could summit this to the next revision of the
> language ?
> If yes, how ?
>
> Vincent

[snip]

I tend to agree that "div" would be better than "/" as a matter of
truth in advertising.  When Ada 83 was designed, many languages in
common use would evaluate 2/3 as integer zero (FORTRAN, C, C++, later
Java, ...).  Pascal was alone, AFAICR, in providing "div" (Modula?).
The "div" seems better than "/" for the same reason I generally like
Ada for teaching new programmers in other aspects: it provides a clue
that the most common meaning of "/", division over Real numbers, which
people learn from from a very early age, does not apply here.
Consequently it decreases by some small amount the probability that a
second's inattention will produce a program bug, such as writing 2 / 3
* n instead of 2 * n / 3.  It's harder, at lease for me, to write 2
div 3 * n without noticing the mistake.  This aligns with Ada's
consistency in id-as-value, in/out parameters, and other clean,
orthagonal features that also reduce the cognitive leap between
program text and semantics.

OTOH, your suggestion probably can't be implemented because it
invalidates so much existing code. Additionally, your version of
Fraction isn't generally useful because 32- or even 64-bit N/D
rationals overflow quickly under multiplication in most realistic
settings, even if lowest terms are maintained by factoring out gcds.
In practice, you'd need to use a numerics tower including bignums,
such as Common Lisp does.

Cheers.