Hardware dependency

Rolf-Thomas Happe rthappe@mathematik.uni-freiburg.de
Sun, 10 May 1998 17:37:17 +0200 (MET DST)


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

What about portability?

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

Yet, Clean is announced as a general purpose programming language for real
world applications.

> I think for the present we should just be grateful that we _can_
> write reasonably fast numerical software in a functional language :-)

I would prefer to be grateful that we can write *correct* numerical software
in a functional language.  Sure, speed matters, too.

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

E. W. Dijkstra writes (in A_Discipline_of_Programming):
"From the above it is clear that explicit refusal by the HSLM
(Hopefully Sufficiently Large Machine), whenever asked to do 
something exceeding its capacity, is a vital feature of the HSLM:
it is necessary for our ability of doing the experiment. There
exist, regretfully enough, machines in which the continuous check
that the simulation of the behaviour of the UM (Unbounded Machine)
is not beyond their capacity is so time-consuming, that this check
is suppressed for the supposed sake of efficiency: whenever the 
capacity would be exceeded by a correct execution, they just
continue - for the supposed sake of convenience - incorrectly.
It is very difficult to use such a machine as a reliable tool, for 
the justification of our belief in the correctness of our answers
produced requires in addition to the proof of the program's
correctness a proof that the computation is not 
beyond the capacity of the machine, and, compared to the first
one, this second proof is a rather formidable obligation."

Side remark: Yes, I know, the IEEE floating point standard defines 
operations involving Infinity, NaNs, ... And abortion is not my 
favourite exception handling scheme.

I should perhaps add, that this issue doesn't have a particular 
practical impact for me, since Clean hasn't been ported to those
platforms I run non-toy programs on.  (I don't want to imply that 
the Clean team should necessarily invest much time in porting their
system to dozens of Unices.)

rthappe