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

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by osa1): @jpbernardy, I think there are couple of different issues involved here; 1. This patch doesn't change anything about GHC-derived method implementations. Standalone deriving was already generating this code, but the documentation isn't talking about this explicitly. (It's saying "GHC does not restrict the form of the data type. Instead, GHC simply generates the appropriate boilerplate code for the specified class, and typechecks it" https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/deriving.htm...) Generated methods are always well-typed, and it's using `error` this way. We merely made non-standalone deriving to work similarly on empty data types, which shouldn't be a problem for anyone, IMO. So the thing you're complaining about was already there for a long time now. We just change some things for consistency and document it. (Also, this patch improves the error message which is always good) 2. I feel like if we force arguments, someone will come here and complain about it too. For example, currently this code works fine: `let g = g in g == g` where type of `g` is empty. If we force it in a non-threaded runtime it'd just loop. (I don't fully understand types-as-contract argument, can you point me to some resources about that?) I also don't care myself, but I feel like we should make this working same as standalone deriving, and document how it is working. Changing standalone deriving for empty types can potentially break existing code, so this may be our only option forward. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7401#comment:32 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC