Hardware dependency

[Alan Hutchinson]

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

First impulse:
Have a few system-defined excptions such as
 - Real overflow
 - head of empty list
which are each identified by a unique number,
and an option for users to extend or overload these with their own, 
e.g.by a "function" such as
   except :: Int -> .a

All these could be caught by another function
   catch :: Int -> .a
which the user is free to define as he wishes.  
If the user does not define it, then there is a default definition:
   catch _  =  undef

The "except" function cannot be defined in user code.
The "catch" function cannot be called in user code.

If ever an exception is caused, and there is a global case for "catch"
matching the exception's number, but no local case in scope, then the 
program's Start function will return the catch value for this number.
For instance, if "catch" is defined as
   catch 22  =  "Folly!" +++ undef
then any exception of number 22 will cause the program to print
   Folly!
and then stop without producing a core dump.
(This contrasts with the Clean 1.1 "abort" and "undef" functions
 which let the programmer EITHER print a message and dump OR 
 do neither.)

If there is a local case of "catch" in scope, then the encompassing
function will return the value of the corresponding case of "catch": e.g.

   myFn ::  ... -> String

   myFn ... = ...
   where
     catch 22 = "Help!"
     ...

"myFn" will return "Help!" if ever exception 22 occurs while it is being
evaluated (unless this exception is caught by some inner case of "catch").

   myFn2 ... = ...
   where
     catch 22 = except 23
     ...

will cause exception 23 within the function which called "myFn2".

This mechanism will not cause side effects, and I think it is
deterministic: any two runs of the same program will behave alike;
so I think it falls within the functional paradigm.  However,
the behaviour of a program will depend on whether functions in it
are declared to be lazy or eager.

I too would be glad to see a bit more detail about the basic types
and their exceptions.  The Clean 1.2 Report says that 
 - Int consists of 32-bit integer values
 - Real    "       64-bit double precision floating point values
Are these IEE standards?  or standards of any other organisation
such as DIN?

Regards, and thanks for Clean!
Alan Hutchinson