Proposal: `Enum` class overhaul
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.
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.
On Dec 13, 2017 11:17 PM, "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.
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
On 2017-12-13 08:22 PM, David Feuer wrote:
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.
participants (2)
-
David Feuer -
M Farkas-Dyck