[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:  monoidal
            Type:  feature request            |           Status:  new
        Priority:  normal                     |        Milestone:  7.8.1
       Component:  Compiler                   |          Version:  7.6.1
      Resolution:                             |         Keywords:  deriving
Operating System:  Unknown/Multiple           |     Architecture:
 Type of failure:  GHC rejects valid program  |  Unknown/Multiple
       Test Case:                             |       Difficulty:  Unknown
        Blocking:                             |       Blocked By:
                                              |  Related Tickets:
----------------------------------------------+----------------------------

Comment (by thoughtpolice):

 I'm very confused here.

 When Simon Marlow announced H2010, EmptyDataDecls is specifically
 mentioned as part of the revision:

 https://groups.google.com/forum/#!topic/fa.haskell/-muu4dzUBJo

 Furthermore, the haskell-prime wiki makes this mention in regards to the
 extension:

 http://ghc.haskell.org/trac/haskell-prime/wiki/EmptyDataDecls

 > The only real issue is whether or not to allow the optional deriving
 clause after an empty declaration, and, if not, on what stage to rule them
 out. Clearly, as there are no data constructors over which to define
 functions, derived instances would (for consistency) have to be everywhere
 undefined. GHC seems to syntactically allow a deriving clause after an
 empty data declaration, but the treats it as a contextual error since no
 interesting instances can be defined. Presumably the reasoning was that
 this gives a more regular syntax and better error messages than ruling out
 deriving for empty declarations syntactically. But the point is that there
 is a choice.

 > For this extension, probably the best course of action is to follow GHC
 and allow deriving () clauses for empty data declarations. That way no
 deriving clause and deriving () still have the same semantics. To do this,
 we syntactically allow all deriving clauses for empty data, but
 semantically limit the clauses to deriving ().

 (Just to note, this is in fact how it now works - 'data Foo deriving ()'
 works just fine, but 'data Foo deriving Eq' is a contextual error.)

 So, I don't think we're deviating from the standard at all in fact, at
 least based on the proposal and what Simon said. Perhaps these parts of
 the standard document were simply overlooked during the editorial process,
 hence the inconsistency? Under my interpretation, H2010 absolutely has
 EmptyDataDecls, and they are "ordinary" data types.

 Now we are back to the original question, which the proposal somewhat
 alluded to. I see this as two separate points:

   * What is more consistent, to reject the instance or create the vacuous
 one? My view is already clear here (that 'ordinary' data types with
 trivial vacuous instances - where there are no constructors - should also
 be derivable.)

   * The standard however, specifically denies this interpretation, as does
 the Haskell' proposal (delta pt 6.) There are two options:
    * Put this behavior under a new flag? Above, Krzysztof mentioned a
 possible `-XEmptyDeriving`.
    * Change the semantics of `-XEmptyDataDecls` and deviate specifically?
 This is a delicate point obviously. Retroactively changing extensions is
 always annoying, but we've been here before, and backwards compatibility
 with a manual instance is doable. This logic kind of flies in the face of
 doing it anyway, at face value - but this is relevant to users. Some
 libraries are very long-term supported, and a 'legacy style' must be dealt
 with. They can simply write manual instances and nothing will ever break.
 Other people who don't care can just use the new behavior.

 Feasibly, whatever we do, this minor amendment could be proposed for
 Haskell 2014. If this is the case, perhaps we should use a new flag.

 I'm personally in favor of doing whatever users want if we can get any
 consensus, because ultimately they maintain the libraries and will
 possibly see the consequences of this change.

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