Hardware dependency

[Rolf-Thomas Happe]

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?