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

[Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de>]

On 5/1/10 8:52 AM, vincent.diemunsch@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 :-).

High school assumptions will haunt us forever. :-)

Maybe von Neumann's sceptic remark about Fortran made in 1954
applies to Ada's operator notation, too.

  Mold it like this: The trouble originates when a programmer
forgets about the important fact that the thing to be
programmed is a computing apparatus.  As such, it has its own
mathematical structures.  As such, it must be given proper
attention.  Formal attention. Then it will turn out to be more
useful and enrich our computing potential.

Surely approaching a computing apparatus with casually
expressed formulas such as 4/3*6 fails on both accounts:
Seen across languages, they are not well defined textual
expressions of a program.  Rather, they hint at mathematical
ideas.   The interpretation 8 as the value of 4/3*6 is only
one of many.  But many possible interpretations would not seem
to be a good thing in the case of  free-standing literals if
you want to achieve clarity of expression.  8 becomes a
possible interpretation only because of a m�lange of evaluation
strategies from which we will have to choose.  Again and again.
But how should we choose when writing formal programs, e.g. in Ada?

1) In programming, mathematics, and elsewhere, / and * are
    massively overloaded symbols. Why incur overload resolution
    into expressions involving literals when instead we could
    add clarity by simply using typed literals and brackets?
    (Resolving overridings or similar would improve litte for
    untyped literals, I think.)  Strategy: Say what you mean.

2) There is only implicit association. Write in two or three
    programming languages regularly and maybe you start adding
    brackets routinely.  Strategy: Add brackets.

LISP, without infix notation, is much less dangerous in this
regard.

With clarity of interpretation in mind, having typed fraction
literals seems as interesting as ever.