[GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.

[GHC]

#7401: Can't derive instance for Eq when datatype has no constructor, while it is
trivial do do so.
-------------------------------------+-------------------------------------
        Reporter:  jpbernardy        |                Owner:
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  7.6.1
      Resolution:                    |             Keywords:  deriving,
                                     |  newcomer
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  GHC rejects       |  Unknown/Multiple
  valid program                      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D978
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Description changed by osa1:

@@ -1,34 +1,10 @@
- mpickering reminded me this ticket so before I leave the ownership of this
- ticket let me write down the current status:
-
- Basically there are a couple of things we can do and we just need someone
- to
- decide which one.
-
- 1. Implement {{{==}}} as {{{_ == _ = True}}}. Pro: this is consistent with
- {{{Void}}}'s {{{Eq}}} instance. Con: I think this lets some bugs to sneak
- in. I think it doesn't make sense to compute things based on equality of
- empty types, so at this point you've probably made a mistake and it's
- better to just bail out.
-
- 2. Implement {{{==}}} as `x == y = case x of {}`. Pro: it fixes the
- problem with (1) and in a good way - you've probably used something like
- {{{error "..."}}} for the empty type terms, so you get your error message.
- Con: this inconsistent with {{{Void}}}.
-
- 3. Leave this as is - no {{{deriving (Eq)}}}. This way we make the user
- decide which behaviour to have. Pro: You can have whatever you want. Con:
- Inconvenient.
-
- These were also discussed at some point but IIRC most people agree that
- these
- are bad ideas:
-
- 4. {{{x == y = error "(==) on empty type"}}}: If it's going to fail it's
- better to fail like (2).
-
- 5. {{{_ == _ = False}}}: Denotationally / type-theoretically bottoms are
- equal or something like that? So it's better to implement (1) instead.
-
- 6. Implement (2), change {{{Void}}}s instance too: Can potentially break
- code.
+ On a "phantom datatype" D, one gets the message:
+ {{{
+ Can't make a derived instance of `Eq D':
+       `D' must have at least one data constructor
+ }}}
+ However there is a trivial, correct instance of Eq D:
+ {{{
+ instance Eq D where
+   (==) = undefined
+ }}}

New description:

 On a "phantom datatype" D, one gets the message:
 {{{
 Can't make a derived instance of `Eq D':
       `D' must have at least one data constructor
 }}}
 However there is a trivial, correct instance of Eq D:
 {{{
 instance Eq D where
   (==) = undefined
 }}}

--

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:47>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler