| By the way, the report says: "Class Enum defines operations
| on sequentially
| ordered types." I think the "sequentially" means that
| multiple applications
| of succ to a value shall not result in the same value. That's
| why I think
| that succ (maxBound :: Int) should be an error and n
Dean Herrington wrote
> It seems to me that the behavior for `(fromInteger x)::Int`, where x is
> an Integer outside Int range, should be the same (in terms of the
> Haskell report) as that for `y + y`, where y is an Int such that
> `toInteger y + toInteger y` is outside Int range.
I agree almost
On Tuesday, February 26, 2002, 15:36:18 EST, David Feuer wrote:
> [...]
> Question: Is there any standard way in Haskell of determining the maximal
> and minimal Int values?
There is one. Use maxBound :: Int and minBound :: Int.
> [...]
By the way, the report says: "Class Enum defines operati
Dean Herington:
> I strongly prefer that that behavior _not_ be provision of any
> normal Int value.
I agree.
I think a operation to let you examine the (possibly) underlying 2s
complement representation without raising an exception should be quite
separate from the operation to convert between
David Feuer writes:
:
| Question: Is there any standard way in Haskell of determining the
| maximal and minimal Int values?
Yes, instance Bounded Int, which means you can use
maxBound :: Int
and
minBound :: Int
___
Haskell mailing list
[E
What about having Int be considered a restricted integer that notices
overflow, and create another type (bit bunch?) that does not notice
overflow, and require explicit conversion to go from one to the other?
This would seem to be the best of both worlds. The "bit bunch" type
could also provide u
It seems to me that the behavior for `(fromInteger x)::Int`, where x is
an Integer outside Int range, should be the same (in terms of the
Haskell report) as that for `y + y`, where y is an Int such that
`toInteger y + toInteger y` is outside Int range. I strongly prefer
that that behavior _not_ b
| It'd be lovely if the Haskell report took a stand on the
| issue, but I suspect that may be too much to hope for.
Actually, it'd be an easy, non-destablising change to make
to the Report to specify the behaviour of the Int instance of
fromInteger on numbers larger than will fit in an Int.
I've recently run up against the following rather annoying
inconsistency between haskell implementations:
HUGS:
Nat> fromInteger 4294967264 :: Int
Program error: {primIntegerToInt 4294967264}
GHCI:
Nat> fromInteger 4294967264 :: Int
-32
I don't have nhc installed at the moment, so I can't tell
