Proposal: `Enum` class overhaul

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

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.

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: `Enum` class overhaul

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.

On Dec 13, 2017 11:17 PM, "M Farkas-Dyck" <[hidden email]> wrote:
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: `Enum` class overhaul

M Farkas-Dyck
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.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries