RE: Enum Int problem

The arithmetic overflow occurs as part of an intermediate result in the
implementation of the arithmetic sequence, and not in the elements of the
sequence itself. It seems to me that it is worthwhile to fix this, and
clarify the definition in the Haskell report so that an Int arithmetic
sequence [start, next .. end] corresponds to the subsequence of the Integer
sequence that are actually Ints in the natural inclusion of Int in Integer.

In terms of the implementation, it is an inexpensive check and does not
involve doing the intermediate computation in the Integer type. For example,
for ascending sequences (next >= start) where step = next - start >= 0, one
just checks if element + step  < element to check for overflow and thus stop
the sequence at element.

Bo


-----Original Message-----
From: Alastair Reid [mailto:alastair@xxxxxxxxxxxxxxxxxxxxxxxxx]
Sent: Wednesday, August 18, 2004 3:59 AM
To: Bo Ilic
Cc: hugs-bugs@xxxxxxxxxxx; glasgow-haskell-bugs@xxxxxxxxxxx
Subject: Re: Enum Int problem


[copied to hugs-bugs]

You shouldn't hope to get any useful results from Int after an arithmetic 
overflow since the Haskell report explicitly says that the results are 
unspecified.  If you want predictable results, you should use Integer or 
Foreign.Int32.  The latter is part of the foreign interface extension which 
is implemented by nhc, ghc and Hugs.

I believe that Hugs is giving a correct answer in this case in that nothing 
strange happens until after the overflow occurs.  Of course the answer is
not 
_useful_ but, as I said, you shouldn't expect useful results after an 
overflow occurs.

I think that GHC may be giving an incorrect answer because I think the 0 
should appear in the list but it would take a very careful examination of
how 
the Haskell report specifies the Enum Int instance to be sure.

--
Alastair Reid

ps When I say 'after an overflow', what I mean is that the value of X is 
undefined if the value of X depends on the value of Y and Y overflowed.

On Friday 13 August 2004 19:39, you wrote:
> Using GHC 6.2.1 interpreter, the fragment [minBound :: Int, 0 ..] returns
> [-2147483648].
>
> Using Hugs, the returned value is the infinite list  [-2147483648, 0,
> -2147483648, 0, ...].
>
> However, I would expect to get [-2147483648, 0]. Similar problems occur
> with the other arithmetic sequence functions for Int when the increment is
> greater than what is representable in the type.