| Both GHC and Hugs have a bug in their Prelude for Ratio's Enum
| instance. The following program
|
|import Ratio
|main = print [ 1, 4%(3::Int) .. 2 ]
|
| should print
|
|[1 % 1,4 % 3,5 % 3,2 % 1]
|
| but instead an infinite list of 1%1s is generated. The reason for this
| is
Marc van Dongen wrote:
Wouldn't that make Enum depend on Ord?
Doesn't seem to make sense if classes are
enumerable but not comparable.
What examples are there of types for which it would be sensible to implement
Enum but not Ord? The concept rather puzzles me. In particular, suppose you
Both GHC and Hugs have a bug in their Prelude for Ratio's Enum
instance. The following program
import Ratio
main = print [ 1, 4%(3::Int) .. 2 ]
should print
[1 % 1,4 % 3,5 % 3,2 % 1]
but instead an infinite list of 1%1s is generated. The reason for this
is that the default method for
George Russell ([EMAIL PROTECTED]) wrote:
: Marc van Dongen wrote:
: Wouldn't that make Enum depend on Ord?
: Doesn't seem to make sense if classes are
: enumerable but not comparable.
Of course above I should have said orderable in stead of comparable.
: What examples are there of types
Sven writes:
Both GHC and Hugs have a bug in their Prelude for Ratio's Enum
instance. ... The reason for this
is that the default method for enumFromThenTo is used, which truncates
4%3 to 1 (same for enumFromTo).
I'd say that this is a bug in the Library
A logical definition of Enum (to me wearing a mathematical hat)
would be
succ x = min { y | y x}
For Ratio this makes no sense, ergo Ratio should not be an
instance of Enum. For Float and Doubles it makes a lot of
sense (giving nextAfter, which is a commonly used IEEE function not
otherwise
George Russell ([EMAIL PROTECTED]) wrote:
: A logical definition of Enum (to me wearing a mathematical hat)
: would be
:
: succ x = min { y | y x}
:
Wouldn't that make Enum depend on Ord?
Doesn't seem to make sense if classes are
enumerable but not comparable.
Regards,
Marc
