[GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
GHC
ghc-devs at haskell.org
Fri Aug 16 19:54:25 CEST 2013
#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
More information about the ghc-tickets
mailing list