generic-deriving
Generic programming library for generalised deriving.
https://github.com/dreixel/generic-deriving
| LTS Haskell 24.17: | 1.14.6@rev:1 | 
| Stackage Nightly 2025-10-31: | 1.14.6@rev:1 | 
| Latest on Hackage: | 1.14.6@rev:1 | 
generic-deriving-1.14.6@sha256:f47c071d90370e0eee27dad6139964bed29b2d896b404b3a9516138f0d92ac55,6755Module documentation for 1.14.6
- Generics- Generics.Deriving
- Generics.Deriving.Base
- Generics.Deriving.ConNames
- Generics.Deriving.Copoint
- Generics.Deriving.Default
- Generics.Deriving.Enum
- Generics.Deriving.Eq
- Generics.Deriving.Foldable
- Generics.Deriving.Functor
- Generics.Deriving.Instances
- Generics.Deriving.Monoid
- Generics.Deriving.Semigroup
- Generics.Deriving.Show
- Generics.Deriving.TH
- Generics.Deriving.Traversable
- Generics.Deriving.Uniplate
 
 
- Generics.Deriving
generic-deriving: Generic programming library for generalised deriving
This package provides functionality for generalising the deriving mechanism in Haskell to arbitrary classes. It was first described in the paper:
- A generic deriving mechanism for Haskell. Jose Pedro Magalhaes, Atze Dijkstra, Johan Jeuring, and Andres Loeh. Haskell’10.
The current implementation integrates with the new GHC Generics. See http://www.haskell.org/haskellwiki/GHC.Generics for more information. Template Haskell code is provided for supporting older GHCs.
This library is organized as follows:
- 
Generics.Deriving.Basedefines the core functionality for GHC generics, including theGeneric(1)classes and representation data types. On modern versions of GHC, this simply re-exportsGHC.Genericsfrombase. On older versions of GHC, this module backports parts ofGHC.Genericsthat were not included at the time, includingGeneric(1)instances.
- 
Generics.Deriving.THimplements Template Haskell functionality for deriving instances ofGeneric(1).
- 
Educational code: in order to provide examples of how to define and use GHC.Generics-based defaults, this library offers a number of modules which define examples of type classes along with default implementations for the classes’ methods. Currently, the following modules are provided:- 
Generics.Deriving.Copoint
- 
Generics.Deriving.ConNames
- 
Generics.Deriving.Enum
- 
Generics.Deriving.Eq
- 
Generics.Deriving.Foldable
- 
Generics.Deriving.Functor
- 
Generics.Deriving.Monoid
- 
Generics.Deriving.Semigroup
- 
Generics.Deriving.Show
- 
Generics.Deriving.Traversable
- 
Generics.Deriving.Uniplate
 It is worth emphasizing that these modules are primarly intended for educational purposes. Many of the classes in these modules resemble other commonly used classes—for example, GShowfromGenerics.Deriving.ShowresemblesShowfrombase—but in general, the classes thatgeneric-derivingdefines are not drop-in replacements. Moreover, the generic defaults thatgeneric-derivingprovide often make simplifying assumptions that may violate expectations of how these classes might work elsewhere. For example, the generic default forGShowdoes not behave exactly likederiving Showwould.If you are seeking GHC.Generics-based defaults for type classes inbase, consider using thegeneric-datalibrary.
- 
- 
Generics.Deriving.Defaultprovides newtypes that allow leveraging the generic defaults in this library using theDerivingViaGHC language extension.
- 
Generics.Derivingre-exportsGenerics.Deriving.Base,Generics.Deriving.Default, and a selection of educational modules.
Changes
1.14.6 [2024.12.05]
- Drop support for GHC 7.10 and earlier.
1.14.5 [2023.08.06]
- Support building with template-haskell-2.21.*(GHC 9.8).
- The Template Haskell machinery now uses TemplateHaskellQuoteswhen building with GHC 8.0+ instead of manually constructing each Template HaskellName. A consequence of this is thatgeneric-derivingwill now build with GHC 9.8, asTemplateHaskellQuotesabstracts over some internal Template Haskell changes introduced in 9.8.
1.14.4 [2023.04.30]
- Allow building with GHC backends where HTYPE_SIG_ATOMIC_Tis not defined, such as the WASM backend.
- Place INLINE [1]pragmas onfromandtoimplementations when types don’t have too many constructors or fields, following the heuristics that GHC 9.2+ uses forGenericderiving.
1.14.3 [2023.02.27]
- Support th-abstraction-0.5.*.
1.14.2 [2022.07.23]
- Fix a bug in which deriveAll1could generate ill kinded code when usingkindSigOptions=False, or when using GHC 8.0 or earlier.
- Fix a bug in which deriveAll1would reject data types whose last type variable has a kind besidesTypeorkon GHC 8.2 or later.
1.14.1 [2021.08.30]
- Backport the Generic(1)instances introduced for tuples (8 through 15) inbase-4.16.
- Make the test suite compile on GHC 9.2 or later.
- Always import Data.Listqualified to fix the build with recent GHCs.
1.14 [2020.09.30]
- Remove instances for Data.Semigroup.Option, which is deprecated as ofbase-4.15.0.0.
- Allow building with template-haskell-2.17.0.0(GHC 9.0).
- Fix a bug in which deriveAll1would needlessly reject data types whose last type parameter appears as an oversaturated argument to a type family.
1.13.1 [2019.11.26]
- Backport the Generic(1)instances forKleisliintroduced inbase-4.14.
1.13 [2019.08.27]
- Make GSemigroupa superclass ofGMonoid. Similarly, makeGSemigroup'a superclass ofGMonoid'.
- In the instance GMonoid (Maybe a), relax the constraint onafromGMonoidtoGSemigroup.
1.12.4 [2019.04.26]
- Support th-abstraction-0.3.0.0or later.
1.12.3 [2019.02.09]
- Support template-haskell-2.15.
- Add a gshowListmethod toGShow, which lets us avoid the need forOverlappingInstancesinGenerics.Deriving.TH. As a consequence, theGShow Stringinstance has been removed, as it is now fully subsumed by theGShow [a]instance (with which it previously overlapped).
- Functions in Generics.Deriving.THnow balance groups of(:*:)and(:+:)as much as possible (deriving Genericwas already performing this optimization, and nowgeneric-derivingdoes too).
- Add a Generics.Deriving.Defaultmodule demonstrating and explaining how and why to useDerivingVia. There is also a test suite with further examples.
1.12.2 [2018.06.28]
- Backport the Generic(1)instances forData.Ord.Down, introduced inbase-4.12. AddGEq,GShow,GSemigroup,GMonoid,GFunctor,GFoldable,GTraversable, andGCopointinstances forDown.
- Refactor internals using th-abstraction.
- Adapt to Maybemoving toGHC.Maybein GHC 8.6.
1.12.1 [2018.01.11]
- Remove a test that won’t work on GHC 8.4.
1.12 [2017.12.07]
- Adapt to the EmptyDataDerivingproposal (introduced in GHC 8.4):- Generics.Deriving.THnow derives- to(1)and- from(1)implementations for empty data types that are strict in the argument.
- Introduce an EmptyCaseOptionsfield toOptionsinGenerics.Deriving.TH, which controls whether generatedfrom(1)/to(1)implementations for empty data types should use theEmptyCaseextension or not (as is the case in GHC 8.4).
- Add mkFrom0Options,mkFrom1Options,mkTo0Options, andmkTo1Optionsfunctions toGenerics.Deriving.TH, which takeEmptyCaseOptionsas arguments.
- The backported instances for V1are now maximally lazy, as perEmptyDataDeriving. (Previously, some instances would unnecessarily force their argument, such as theEqandOrdinstances.)
- Add instances for V1inGenerics.Deriving.Copoint,.Eq,.Foldable,.Functor,.Show, and.Traversable.
 
- Remove the bitrotting simplInstancefunction fromGenerics.Deriving.TH.
1.11.2 [2017.04.10]
- Add GEq,GShow,GEnum, andGIxinstances for the new data types inForeign.C.Types(CBool) andSystem.Posix.Types(CBlkSize,CBlkCnt,CClockId,CFsBlkCnt,CFsFilCnt,CId,CKey, andCTimer) introduced inbase-4.10.0.0
1.11.1 [2016.09.10]
- Fix Template Haskell regression involving data families
- Convert examples to test suite
- Backport missing DataandTypeableinstances forRec1,M1,(:*:),(:+:), and(:.:)
1.11
- 
The behavior of functions in Generics.Deriving.THhave changed with respect to when type synonyms are generated forRep(1)definitions. In particular:- By default, deriveRepresentable(1)will no longer define itsRep(1)type family instance in terms of the type synonym that has to be generated withderiveRep(1). Similarly,deriveAll(1)andderiveAll0And1will no longer generate a type synonym. Instead, they will generateGeneric(1)instances that directly define theRep(1)instance inline. If you wish to revert to the old behavior, you will need to use the variants of those functions suffixed with-Options.
- New functions makeRep0InlineandmakeRep1Inlinehave been added which, for most purposes, should replace uses ofmakeRep0/makeRep0FromTypeandmakeRep1/makeRep1FromType(but see the next bullet point for a caveat).
- The use of deriveRep(1),makeRep0/makeRep0FromType, andmakeRep1/makeRep1FromTypeare now discouraged, but those functions are still available. The reason is that on GHC 7.0/7.2/7.4, it is impossible to usemakeRep0Inline/makeRep1Inlinedue to a GHC bug. Therefore, you must usemakeRep0/makeRep1andderiveRep(1)on GHC 7.0/7.2/7.4 out of necessity.
 These changes make dealing with Genericinstances that involvePolyKindsandTypeInTypemuch easier.
- By default, 
- 
All functions suffixed in -WithKindSigsinGenerics.Deriving.THhave been removed in favor of a more sensible-Optionssuffixing scheme. The ability to toggle whether explicit kind signatures are used on type variable binders has been folded intoKindSigOptions, which is an explicit argument toderiveRep0Options/deriveRep1Optionsand also a field in the more general ‘Options’ data type.
- 
Furthermore, the behavior of derived instances’ kind signatures has changed. By default, the TH code will now always use explicit kind signatures whenever possible, regardless of whether you’re working with plain data types or data family instances. This makes working with TypeInTypeless surprising, but at the cost of making it slightly more awkward to work with derivedGeneric1instances that constrain kinds to*by means of(:.:).
- 
Since Generic1is polykinded on GHC 8.2 and later, the functions inGenerics.Deriving.THwill no longer unify the kind of the last type parameter to be*.
- 
Fix a bug in which makeRep(and similarly named functions) would not check whether the argument type can actually have a well kindedGeneric(1)instance.
- 
Backport missing FoldableandTraversableinstances forRec1
1.10.7
- Renamed internal modules to avoid using apostrophes (averting this bug: https://github.com/haskell/cabal/issues/3631)
1.10.6
- A new base-4-9Cabal flag was added to more easily facilitate installinggeneric-derivingwith manually installed versions oftemplate-haskell.
1.10.5
- Apply an optimization to generated to(1)/from(1)instances that factors out common occurrences ofM1. See http://git.haskell.org/ghc.git/commit/9649fc0ae45e006c2ed54cc5ea2414158949fadb
- Export internal typeclass names
- Fix Haddock issues with GHC 7.8
1.10.4.1
- Fix Haddock parsing issue on GHC 8.0
1.10.4
- Backported MonadPlusandMonadZipinstances forU1, and made theFunctor,Foldable,Traversable,Alternative, andMonadinstances forU1lazier to correspond withbase-4.9
1.10.3
- Backported Enum,Bounded,Ix,Functor,Applicative,Monad,MonadFix,MonadPlus,MonadZip,Foldable,Traversable, andDatainstances (introduced inbase-4.9) for datatypes in theGenerics.Deriving.Basemodule
1.10.2
- Fix TH regression on GHC 7.0
1.10.1
- Added Generics.Deriving.Semigroup
- Added GMonoidinstance forData.Monoid.Alt
- Fixed a bug in the GEnuminstances for unsignedIntegraltypes
- Added Safe/Trustworthypragmas
- Made instances polykinded where possible
1.10.0
- On GHC 8.0 and up, Generics.Deriving.THuses the new type literal-based machinery
- Rewrote the Template Haskell code to be robust. Among other things, this fixes
a bug with deriving Generic1 instances on GHC 7.8, and makes it easier to
derive Generic1 instances for datatypes that utilize GHC 8.0’s -XTypeInTypeextension.
- Added deriveAll0andmakeRep0for symmetry withderiveAll1andmakeRep1
- AddedmakeRep0FromTypeandmakeRep1FromTypeto make it easier to pass in the type instance (instead of having to pass each individual type variable, which can be error-prone)
- Added functions with the suffix -WithKindSigsto allow generating type synonyms with explicit kind signatures in the presence of kind-polymorphic type variables. This is necessary for some datatypes that use-XTypeInTypeto have derivedGeneric(1)instances, but is not turned on by default since the TH kind inference is not perfect and would cause otherwise valid code to be rejected. Use only if you know what you are doing.
- Fixed bug where a datatype with a single, nullary constructor would generate
incorrect Genericinstances
- More sensible GEnuminstances for fixed-size integral types
- Added GCopoint,GEnum,GEq,GFoldable,GFunctor,GMonoid,GShow, andGTraversableinstances for datatypes introduced in GHC 8.0
- Backported Generic(1)instances added in GHC 8.0. Specifically,Genericinstances forComplex(base-4.4and later)ExitCode, andVersion; andGeneric1instances forComplex(base-4.4and later) andProxy(base-4.7and later). AddedGEnum,GEq,GFoldable,GFunctor,GIx,GShow, andGTraversableinstances for these datatypes where appropriate.
1.9.0
- Allow deriving of Generic1 using Template Haskell
- Allow deriving of Generic(1) for data families
- Allow deriving of Generic(1) for constructor-less plain datatypes (but not data families, due to technical restrictions)
- Support for unboxed representation types on GHC 7.11+
- More GCopoint,GEnum,GEq,GFoldable,GFunctor,GIx,GMonoid,GShow, andGTraversableinstances
- The field accessors for the (:+:)type inGenerics.Deriving.Basehave been removed to be consistent withGHC.Generics
- Ensure that TH generates definitions for isNewtype and packageName, if a recent-enough version of GHC is used
- Ensure that TH-generated names are unique for a given data type’s module and package (similar in spirit to Trac #10487)
- Allow building on stage-1 compilers
