Proposal: `Enum` class overhaul

[M Farkas-Dyck]

I propose to add some new methods of `Enum`:

class Enum a where
...

predMay, succMay :: a -> Maybe a
toEnum' :: Integer -> Maybe a
fromEnum' a -> Integer

Rationale for `fromEnum'` and `toEnum'`:

The docs for `Enum` now say the minimal complete definition is `toEnum` and `fromEnum`, but this is not enough to have sane default instances of the other methods, for example:

data ABC = A | B | C deriving Show
instance Enum ABC where
toEnum 0 = A
toEnum 1 = B
toEnum 2 = C
fromEnum A = 0
fromEnum B = 1
fromEnum C = 2

main = print [A ..] -- [A,B,C,*** Exception: Non-exhaustive patterns in function toEnum

In this case one could merely derive `Enum`, but not in some other cases, e.g. numeric types or GADTs. It is not possible to do better defining `toEnum` and `fromEnum` alone.

If we default-define `toEnum'` and `fromEnum'` and their evil (i.e. partial) syblings in terms of each other, the user need merely define the total methods.

Using `Integer` rather than `Int` allows these methods to not fail for types larger than an `Int`, which are not uncommon on 32-bit systems.

Rationale for `predMay` and `succMay`:

I include these partly for completeness, but `predMay` can not now be defined in general, and `succMay` only cumbersomely in terms of `enumFrom`.

Note: All rationales imply "unless one uses `unsafePerformIO`". I'd rather not, myself.

[David Feuer]

I'm moderately opposed, on the basis that the Enum class is too
fundamentally broken/meaningless to be worth fiddling with. It attempts to
serve multiple barely-related purposes at once, and serves none of them
terribly well.

Post by M Farkas-Dyck
class Enum a where
...
predMay, succMay :: a -> Maybe a
toEnum' :: Integer -> Maybe a
fromEnum' a -> Integer
The docs for `Enum` now say the minimal complete definition is `toEnum`
and `fromEnum`, but this is not enough to have sane default instances of
data ABC = A | B | C deriving Show
instance Enum ABC where
toEnum 0 = A
toEnum 1 = B
toEnum 2 = C
fromEnum A = 0
fromEnum B = 1
fromEnum C = 2
main = print [A ..] -- [A,B,C,*** Exception: Non-exhaustive patterns in function toEnum
In this case one could merely derive `Enum`, but not in some other cases,
e.g. numeric types or GADTs. It is not possible to do better defining
`toEnum` and `fromEnum` alone.
If we default-define `toEnum'` and `fromEnum'` and their evil (i.e.
partial) syblings in terms of each other, the user need merely define the
total methods.
Using `Integer` rather than `Int` allows these methods to not fail for
types larger than an `Int`, which are not uncommon on 32-bit systems.
I include these partly for completeness, but `predMay` can not now be
defined in general, and `succMay` only cumbersomely in terms of `enumFrom`.
Note: All rationales imply "unless one uses `unsafePerformIO`". I'd rather not, myself.
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

[M Farkas-Dyck]

I'm moderately opposed, on the basis that the Enum class is too fundamentally broken/meaningless to be worth fiddling with. It attempts to serve multiple barely-related purposes at once, and serves none of them terribly well.

I agree it's bad, but `..` syntax is defined in terms of it, and trying to introduce breaking modifications into base is like trying to introduce my head into a brick wall.