Original-Via: [+JANET.00007110000400.23429052424290/ftp.mail]; Tue, 5 Nov 91 09:35:59
GMT
wrt Float/Real operations: I suggest you look at the notion of exactness
in Scheme, which effectively allows one to distinguish between when numbers
must behave mathematically, and when close is good enough.
As for (integer) overflow, there are two possible positions: when numbers
get too big for portability (28 bits or whatever the book says); or when
they get big enough that the answers are wrong (ie. at the bounds of the
representation). Checking for the first might reasonably be optional;
checking for the second is not, and should always take place. (The only
exception might be if an explicit assertion that no check were needed was
present (preferably with a proof/justification and the authors `signature')).
(Incidentally, I would argue strongly that the `truncated value' option on
overflow is horribly dangerous; apart from anything else, it means that Int
may then be a modular arithmetic, which is very different from expectations.)
(Having infinite values (either affine or projective) may be all right, but
notice that the rules are different; for example, (n+k)-k is not always n
(eg. if the addition overflows to +oo) (cf. n+k patterns stuff).)
> 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.
This seems somewhat arbitrary: if there is some reason why your numbers
should be small, then check for that, explicitly, to make it clear;
but "big numbers => probable bug" sounds dodgy to me!
Dave Bruce
[Caveat: the usual sort of thing - personal statement, not corporate; etc]
> 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!
We put a..b types into Ten15, and found them quite useful. Unfortunately,
when coupled with proper polymorphism, the type system then becomes
(provably) undecidable, in general! Never found a good remedy for that...
