Prelude.Linear.Internal.Generically

A datatype whose instances are defined generically, using the Generic representation. Generically1 is a higher-kinded version of Generically that uses Generic1.

Generic instances can be derived via Generically A using -XDerivingVia.

{-# LANGUAGE DeriveGeneric      #-}
{-# LANGUAGE DerivingStrategies #-}
{-# LANGUAGE DerivingVia        #-}

import GHC.Generics (Generic)

data V4 a = V4 a a a a
  deriving stock Generic

  deriving (Semigroup, Monoid)
  via Generically (V4 a)

This corresponds to Semigroup and Monoid instances defined by pointwise lifting:

instance Semigroup a => Semigroup (V4 a) where
  (<>) :: V4 a -> V4 a -> V4 a
  V4 a1 b1 c1 d1 <> V4 a2 b2 c2 d2 =
    V4 (a1 <> a2) (b1 <> b2) (c1 <> c2) (d1 <> d2)

instance Monoid a => Monoid (V4 a) where
  mempty :: V4 a
  mempty = V4 mempty mempty mempty mempty

Historically this required modifying the type class to include generic method definitions (-XDefaultSignatures) and deriving it with the anyclass strategy (-XDeriveAnyClass). Having a /via type/ like Generically decouples the instance from the type class.

Tag for M1: record selector

Type synonym for encoding meta-information for datatypes

Type synonym for encoding meta-information for constructors

Type synonym for encoding meta-information for record selectors

Types with nonlinear or multiplicity-polymorphic fields should use MP1 under S1. Unfortunately, Template Haskell (and GHC Generics) currently lack any support for such types, so their instances must currently be written entirely manually. We may add some functions to ease the pain at some point.

Generic-deriving classes that do not involve linear types should treat MP1 m much as they treat M1: dig through it to get to the meat. Unfortunately, some futzing about may be necessary to convince the type checker that multiplicities work out.

Generic-deriving classes that use linear types may have to treat MP1 m specially. In particular, they may need to constrain m to be 'One or 'Many, or to match some other type variable.

Products: encode multiple arguments to constructors

Sums: encode choice between constructors

Void: used for datatypes without constructors

The composition operator for types. We use our own here because for many classes, it's possible to share generic deriving classes between GHC.Generics and Generics.Linear by just instantiating them for both composition operators (and MP1).

Generic is exactly the same as GHC.Generics.Generic except that to and from are multiplicity polymorphic. This means they will work equally well in traditional Haskell code and in linearly typed code.

Generic1 is similar to GHC.Generics.Generic1, but has a few differences.

Multiplicity polymorphism

As with Generic, the to1 and from1 methods are multiplicity polymorphic.

Differences in Rep1 representation

Rec1 is not used

Given a type like

newtype Foo a = Foo (Maybe a)

where a single type constructor (here Maybe) is applied to the parameter, GHC.Generics represents the field as Rec1 Maybe. We instead represent it using Par1 :.: Maybe. It is expected that very few real-life uses of GHC.Generics will break as a result, and this simplification means that users don't have to write Rec1 instances for their generic-deriving classes.

Compositions associate in the opposite order

Given a type like

newtype Bar a = Bar (Maybe [Either e a])

where multiple type constructors are layered around the parameter, "GHC.Generics@ represents the field as

Maybe :.: ([] :.: Rec1 (Either e))

We instead represent it as

((Par1 :.: Maybe) :.: []) :.: Either e

Doing it this way prevents to1 and from1 from having to fmap newtype constructors through the composed types, which can be a considerable performance improvement and enables multiplicity polymorphism.

In most cases, modifying generic-deriving classes to accommodate this change is simple: just swap which side of the composition is treated as a generic representation and which as a base type. In a few cases, more restructuring will be needed, which will require using different generic-deriving classes than for GHC.Generics.

Difference in specificity

Users of type application will need to be aware that the kind parameter for Generic1 is marked as inferred, whereas for GHC.Generics.Generic1 it is marked as specified. So you should use, for example, to1 @Maybe rather than to1 @_ @Maybe.