Original-Via: uk.ac.ed.mrcvax; Mon, 4 Nov 91 17:16:03 GMT
Original-Via: talisker.hgu; Mon, 4 Nov 91 17:15:05 GMT
| > "The results of exception conditions (such as overflow or underflow) on
| > the fixed-precision numeric types are undefined; and implementations
| > may choose error (bottom, semantically), a truncated value, or a special
| > value such as infinity, indefinite, etc"
| >
| > Surely this is unacceptable? It is unavoidable that a program
| > might run on one implementation and fail on another, but is it not
| > a basic principle of the language that two implementations
| > will deliver identical results if they deliver results at all?
| >
| > Ian
|
| No. Fixed-precision floating-point could not really be supported under
| the principal you quote (different FP representations *will* yield
| different results in certain conditions).
Only because we are not prepared to bear the cost of insisting on a standard
representation and set of operations for floats (which must exits).
Anyway, floating-point numbers are something of a special case --- I _expect_
any finite representation of real numbers to yield non-deterministic results
in some cases.
| As long as all Int values remain within the SUPPORTED RANGE for type
| Int (28 bits?) then any two implementations will deliver the same
| results for Int values. REQUIRING overflow checking would be rather
| Draconian for some architectures -- I would certainly want it as an
| option, though, if possible!
I think that the compiler option you suggest (offer?!) is highly desirable.
I would suggest that the option checks for overflow of the 28bits stated
as the minimum requirement in the manual --- one could then be sure that
a given program/input would run on any valid Haskell implementation. I admit
that I would be the first to yell if the overflow checking could not be
disabled!
| You have the option of using Rationals and Integers if you wish to
| avoid all overflow and representation problems. There is a
| performance penalty, but this is the cost of absolute reliability
| in this case.
In a sense Integers give me less security. My interest in Haskell is
for engineering ``safety-critical'' systems, but in fact I require
only to achieve partial correctness (is that the right term?), unlike the
fly-by-wire and nuclear reactor people. If my Ints get bigger than
28 bits then chances are something's gone wrong and I would rather my
program returned bottom.
Finally, I recall my First Love (now long separated) --- Pascal.
Its sub-range types (eg ``day = 1..31'') at once improved readability,
security and, (if the compiler writer could be bothered) efficiency.
Sigh!
Ian
