Re: another way to shoot yourself in the foot?

[Colin Paul Gloster <Colin_Paul_Gloster@ACM.org>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=UTF-8, Size: 2454 bytes --]

On Thu, 10 Jul 2008, James Giles wrote:

|-----------------------------------------------------------------------|
|"[..]                                                                  |
|                                                                       |
|[..]  For example                                                      |
|(and I think this is the original context), integer arithmetic should  |
|be exact if it doesn't overflow.  No one would accept an implementation|
|that did otherwise, but the standard should actually require it."      |
|-----------------------------------------------------------------------|

I am not sure which of "an implementation of Fortran" and "an
implementation of any language" "an implementation" was an
abbreviation of above.

In 1999, the Java BigInteger class was not required to provide exact
arithmetic in the absence of overflow.

|-----------------------------------------------------------------------|
|"Many other languages also don't explicitly require such things.       |
|I'm not certain that Ada does."                                        |
|-----------------------------------------------------------------------|

This has been required of Ada for over twenty-five years. From
HTTP://archive.AdaIC.com/standards/83lrm/html/lrm-03-05.html#3.5.4
:"[..]

The same arithmetic operators are predefined for all integer types
(see 4.5). The exception NUMERIC_ERROR is raised by the execution of
an operation (in particular an implicit conversion) that cannot
deliver the correct result (that is, if the value corresponding to the
mathematical result is not a value of the integer type). [..]

[..]"

I am grateful to James Giles; Dick Hendrickson; François Jacq;
and Richard Maine for their helpful and clearly time-consuming
clarifications of Fortran semantics and tool issues. It is unfortunate
that Richard Maine ignored that every time I pointed out that Ada
suffers from some of these problems. It was clear from the reponses
however, that Ada is better overall. No language is perfect and a
number of theorems from computer science show that no language can be
perfect.

Just because I am convinced that Ada is better overall does not mean
that I shall never use Fortran, so I hope that news:comp.lang.fortran
participants will be helpful again when I need help with the language
again.

With best regards,
Nicholas Colin Paul Gloster