Hardware dependency
Rolf-Thomas Happe
rthappe@mathematik.uni-freiburg.de
Sat, 9 May 1998 19:57:33 +0200 (MET DST)
The lack of responses to my previous message `Arithmetics' on the
deficiencies of the specification & implementation of arithmetics
makes me suspect that it was perceived as an impolite attack.
I'm going to rephrase its content in a hopefully more digestible way.
The Clean report (1.1) doesn't seem to deal with arithmetical limitations
and exceptions. My version of Clean (Clean 1.1 on a SPARCstation 4
running SunOS 5.5) doesn't do arbitrary precision arithmetics, but it
doesn't give access to the information wether an arithmetical
exception, e.g. a signed integer overflow, has occured, either.
And even if a particular Clean program can be proved to work
correctly provided numbers in a certain range are representable:
these requirements can't be expressed (directly) in the program (for
example in the manner of Fortran90's `type parameters');
the limits imposed by the representation of numbers aren't stated
anywhere (contrast this with C's infamous header files, which tell
INT_MAX, INT_MIN, ..., at least (that really is the very least)).
The benefits of declarative programming are somewhat spoiled by
unreliable arithmetics.
A particular nuisance in my version of Clean is mod: -1 mod 3
evaluates to -1, while I'd expect 2.
If the Clean team has a concept of modulo different from mine --
the report doesn't say what mod(ulo) is meant to calculate anyway.
The definition of mod is left to a random hardware operator, as it seems.
As for floating point numbers: since Clean isn't forbidden to produce
non-numbers (and not-really-numbers such as `infinity'), predicates
that tell real Reals from the others seem essential (to me).
A compiler switch that, on floating point exceptions, drove the
Clean runtime system into suicide, would be both nice and easily
feasible (on some platforms).
rthappe
PS: Does exception handling fit into a pure functional language?