Hardware dependency

[Adrian Hey]

On Sat 09 May, Rolf-Thomas Happe wrote:
> 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.

Good idea, I think the reason you didn't get much response is that you didn't
say exactly what you thought was wrong.
 
> The Clean report (1.1) doesn't seem to deal with arithmetical limitations
> and exceptions.  

The Clean 1.2 report doesn't seem to either, but my guess is you could
probably find out most of what you want to know by looking in the manual
of a C compiler for your platform.

> 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.

Traditionally functional programming languages have been used for
symbolic rather than numerical applications, so I suppose the Clean
Team have given this sort of thing fairly low priority in the past.
I think for the present we should just be grateful that we _can_
write reasonably fast numerical software in a functional language :-)
No doubt these problems will be addressed in due course. 

> 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.

I would aggree with your definition of 'mod', but I've found that often
programming languages don't seem to work this way for negative Nos.
I've never really understood why, I just assumed that it was me who
was stupid and so learned to live with it without griping :-)

> 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).

Seems like a reasonable idea to me. I suppose you could try to write
your own by using 'toString' (or 'fromReal' ??) and then looking at
the resulting string. I haven't tried this though, and even if it works
it would probably be a bit slow.

> 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).

Nice? Don't you mean nasty? I don't think a program should _ever_ be
designed to 'bomb out' on users, unless you know that you are going
to be the only user. This sort of thing is generally indicative of
software bugs and shouldn't be part of your design goals. Unfortunately,
even nowadays there are far too many programs (even operating systems) in
the world which do precisely this :-)

> PS: Does exception handling fit into a pure functional language?

This is a question of great interest to me. But if I get started on this
subject I'll end up writing another essay, so I'd better stop now.

Regards
-- 
Adrian Hey