[Haskell-cafe] instance Enum Double considered not entirely great?

Chris Smith cdsmith at gmail.com
Sun Sep 25 19:20:52 CEST 2011

Would it be an accurate summary of this thread that people are asking
for (not including quibbles about naming and a few types):

class Ord a => Enum a where
    succ :: a -> a
    pred :: a -> a
    fromEnum :: a -> Int(eger)
    toEnum :: Int(eger) -> a
-- No instance for Float/Double

class Ord a => Range a where
    rangeFromTo :: a -> a -> [a] -- subsumes Ix.range / Enum.enumFromTo
    rangeFromThenTo :: a -> a -> a -> [a]
    inRange   :: (a, a) -> a -> Bool
-- Does have instances for Float/Double.  List ranges desugar to this.
-- Also has instances for tuples

class Range a => InfiniteRange a where -- [1]
    rangeFrom :: a -> [a]
    rangeFromThen :: a -> a -> [a]
-- Has instances for Float/Double
-- No instances for tuples

class Range a => Ix a where
    index     :: (a, a) -> a -> Int
    rangeSize :: (a, a) -> Int

-- Again no instances for Float/Double.  Having an instance here implies
-- that the rangeFrom* are "complete", containing all 'inRange' values

class (RealFrac a, Floating a) => RealFloat a where
    ... -- existing stuff
    (.<.), (.<=.), (.>.), (.>=.), (.==.) :: a -> a -> Bool
        -- these are IEEE semantics when applicable

instance Ord Float where ... -- real Ord instance where NaN has a place

There would be the obvious properties stated for types that are
instances of both Enum and Range, but this allows for non-Enum types to
still be Range instances.

If there's general agreement on this, then we at least have a proposal,
and one that doesn't massively complicate the existing system.  The next
step, I suppose would be to implement it in an AltPrelude module and
(sadly, since Enum is changing meaning) a trivial GHC language
extension.  Then the real hard work of convincing more people to use it
would start.  If that succeeds, the next hard work would be finding a
compatible way to make the transition...

I'm not happy with InfiniteRange, but I imagine the alternative (runtime
errors) won't be popular in the present crowd.


More information about the Haskell-Cafe mailing list