Contradictions about DeriveDataTypeable in the manual?

Exhibit A:
With -XDeriveDataTypeable, you can derive instances of the class Data, defined in Data.Data. See "Deriving Typeable instances" for deriving Typeable.
Exhibit B:
-XDeriveDataTypeable Enable automatic deriving of instances for the Typeable typeclass
Exhibit C:
Derived instances of Typeable are ignored, and may be reported as an error in a later version of the compiler.
---------------- A and B seem contradictory: Is this extension for deriving Data, or for deriving Typeable? B and C seem... not technically contradictory, but why is there an extension that enables the deriving of instances that will just be ignored? Is this extension meant to be deprecated?
From experimentation, it seems like all types automatically get Typeable instances whether you declare it or not. Is that accurate?

In the old days, DeriveDataTypeable enabled deriving both Data and
Typeable. As of a fairly recent GHC version (7.10? 8.0?), Typeable
instances are indeed derived automatically for all types that can get
such instances, so DeriveDataTypeable is only used for deriving Data
instances. I can't say whether it will ever be an error to write an
explicit `deriving Typeable` clause, but I don't see much point in
making it one.
Unrelatedly, 8.2 has a complete overhaul of Typeable that you should
take a look at if you're interested in the class. The new
Type.Reflection API is much more powerful than the old Data.Typeable
one.
On Mon, Jun 26, 2017 at 1:17 PM, Chris Martin
Exhibit A:
With -XDeriveDataTypeable, you can derive instances of the class Data, defined in Data.Data. See "Deriving Typeable instances" for deriving Typeable.
Exhibit B:
-XDeriveDataTypeable Enable automatic deriving of instances for the Typeable typeclass
Exhibit C:
Derived instances of Typeable are ignored, and may be reported as an error in a later version of the compiler.
----------------
A and B seem contradictory: Is this extension for deriving Data, or for deriving Typeable?
B and C seem... not technically contradictory, but why is there an extension that enables the deriving of instances that will just be ignored?
Is this extension meant to be deprecated?
From experimentation, it seems like all types automatically get Typeable instances whether you declare it or not. Is that accurate?
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Thanks. I've opened a PR on GitHub to update the docs:
https://github.com/ghc/ghc/pull/48
On Mon, Jun 26, 2017 at 2:05 PM David Feuer
In the old days, DeriveDataTypeable enabled deriving both Data and Typeable. As of a fairly recent GHC version (7.10? 8.0?), Typeable instances are indeed derived automatically for all types that can get such instances, so DeriveDataTypeable is only used for deriving Data instances. I can't say whether it will ever be an error to write an explicit `deriving Typeable` clause, but I don't see much point in making it one.
Unrelatedly, 8.2 has a complete overhaul of Typeable that you should take a look at if you're interested in the class. The new Type.Reflection API is much more powerful than the old Data.Typeable one.
On Mon, Jun 26, 2017 at 1:17 PM, Chris Martin
wrote: Exhibit A:
With -XDeriveDataTypeable, you can derive instances of the class Data, defined in Data.Data. See "Deriving Typeable instances" for deriving Typeable.
Exhibit B:
-XDeriveDataTypeable Enable automatic deriving of instances for the Typeable typeclass
Exhibit C:
Derived instances of Typeable are ignored, and may be reported as an error in a later version of the compiler.
----------------
A and B seem contradictory: Is this extension for deriving Data, or for deriving Typeable?
B and C seem... not technically contradictory, but why is there an extension that enables the deriving of instances that will just be ignored?
Is this extension meant to be deprecated?
From experimentation, it seems like all types automatically get Typeable instances whether you declare it or not. Is that accurate?
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
participants (2)
-
Chris Martin
-
David Feuer