fromInteger :: Integer -> Int/Word

[Alastair Reid]

Ross Paterson <ross@soi.city.ac.uk> writes:
> Under Hugs, fromInteger (and thus fromIntegral) throws an exception
> if the argument is outside the representable range of values, while
> GHC just truncates.  

I would say that GHC implements a performance optimization by dropping
the check and that the behaviour outside the range of Int should be
treated as undefined (which is not the same as 'implementation
defined').

> And some of the libraries rely on the GHC behaviour.

I would say that such code is broken since it relies on a non-portable
feature.

I use 'non-portable' both in the sense that code depends on a quirk of
one implementation and in the sense that the code will behave
differently on different architectures.

> It seems it's not a matter of principle with Hugs, since
> operations on Int or Word silently overflow, 

It is hard to write portable C code which detects integer overflow for
addition, multiplication, division, etc. so Hugs punts in this
exceptional case.

> as do the built-in conversions between Int and Word types.

I think that would be easy to fix and should be done.

(Alternatively, one could argue that since Int and Word are required
to have the same bit size, the conversion should follow the same
pattern as for Int<m> <-> Word<n> where m==n.  I prefer to regard Int
and Word as types whose portability issues should be brought to the
users attention as often as possible in the hope that they will be
encouraged to think about writing their code using portable types.)


In general, I think libraries should be restricted to that behaviour
which can be provided in a portable way and, where feasible, libraries
should check that they are used in that portable way.  Exceptions to
this are where the test is hard to implement or maintain or interfere
with other goals of the compiler (speed for GHC, portability for
Hugs).

--
Alastair Reid                 alastair@reid-consulting-uk.ltd.uk  
Reid Consulting (UK) Limited  http://www.reid-consulting-uk.ltd.uk/alastair/

ps This reminds me: I should add code to detect when 'unsafe' ffi
calls and finalizers call back into the Hugs evaluator.  Also, we
should treat all ffi calls inside a call to unsafePerformIO as
'unsafe' since they cannot safely reenter the Hugs evaluator (for the
same reason that finalizers are not allowed to).