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

#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 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