Functor module:Data

A type f is a Functor if it provides a function fmap which, given any types a and b, lets you apply any function of type (a -> b) to turn an f a into an f b, preserving the structure of f.

Examples

>>> fmap show (Just 1)  --  (a   -> b)      -> f a       -> f b
Just "1"                --  (Int -> String) -> Maybe Int -> Maybe String

>>> fmap show Nothing   --  (a   -> b)      -> f a       -> f b
Nothing                 --  (Int -> String) -> Maybe Int -> Maybe String

>>> fmap show [1,2,3]   --  (a   -> b)      -> f a       -> f b
["1","2","3"]           --  (Int -> String) -> [Int]     -> [String]

>>> fmap show []        --  (a   -> b)      -> f a       -> f b
[]                      --  (Int -> String) -> [Int]     -> [String]

The fmap function is also available as the infix operator <$>:

>>> fmap show (Just 1) --  (Int -> String) -> Maybe Int -> Maybe String
Just "1"

>>> show <$> (Just 1)  --  (Int -> String) -> Maybe Int -> Maybe String
Just "1"

A type f is a Functor if it provides a function fmap which, given any types a and b lets you apply any function from (a -> b) to turn an f a into an f b, preserving the structure of f. Furthermore f needs to adhere to the following:

• Identity fmap id == id
• Composition fmap (f . g) == fmap f . fmap g

Note, that the second law follows from the free theorem of the type fmap and the first law, so you need only check that the former condition holds. See https://www.schoolofhaskell.com/user/edwardk/snippets/fmap or https://github.com/quchen/articles/blob/master/second_functor_law.md for an explanation.

A type f is a Functor if it provides a function fmap which, given any types a and b lets you apply any function from (a -> b) to turn an f a into an f b, preserving the structure of f. Furthermore f needs to adhere to the following:

• Identity fmap id == id
• Composition fmap (f . g) == fmap f . fmap g

Note, that the second law follows from the free theorem of the type fmap and the first law, so you need only check that the former condition holds.

Bidirectional version of Data.Functor.

An invariant version of Functor, equivalent to Invariant.

Linear Data Functors should be thought of as containers holding values of type a over which you are able to apply a linear function of type a %1-> b on each value of type a in the functor and consume a given functor of type f a.

Poly-kinded Functor type class. KFunctor generalizes functors, bifunctors, profunctors, ... by declaring a list of Variances for a type constructor.

Eliminator functions for data types in the Data.Functor.* module namespace. All of these are re-exported from Data.Eliminator with the exceptions of Sum and Product, as these clash with eliminators of the same names in Data.Eliminator.Semigroup and Data.Eliminator.Monoid.

Consider the category of Haskell quivers with

• objects are types of higher kind

• p :: k -> k -> Type

• morphisms are terms of RankNType,

• forall x y. p x y -> q x y

• identity is id
• composition is .

There is a natural hierarchy of typeclasses for endofunctors of the category of Haskell quivers, analagous to that for Haskell types.

An adapter newtype, suitable for DerivingVia. Its Eq1, Ord1, Read1, and Show1 instances leverage Generic1-based defaults.

A Functor with an additional index. Instances must satisfy a modified form of the Functor laws:

imap f . imap g ≡ imap (\i -> f i . g i)
imap (\_ a -> a) ≡ id

Barbie-types that can be mapped over. Instances of FunctorB should satisfy the following laws:

bmap id = id
bmap f . bmap g = bmap (f . g)

There is a default bmap implementation for Generic types, so instances can derived automatically.

Functor from indexed-types to indexed-types. Instances of FunctorT should satisfy the following laws:

tmap id = id
tmap f . tmap g = tmap (f . g)

There is a default tmap implementation for Generic types, so instances can derived automatically.

For a good explanation of profunctors in Haskell see Dan Piponi's article: http://blog.sigfpe.com/2011/07/profunctors-in-haskell.html For more information on strength and costrength, see: http://comonad.com/reader/2008/deriving-strength-from-laziness/

Formally, the class Profunctor represents a profunctor from Hask -> Hask. Intuitively it is a bifunctor where the first argument is contravariant and the second argument is covariant. You can define a Profunctor by either defining dimap or by defining both lmap and rmap. If you supply dimap, you should ensure that:

dimap id id ≡ id

If you supply lmap and rmap, ensure:

lmap id ≡ id
rmap id ≡ id

If you supply both, you should also ensure:

dimap f g ≡ lmap f . rmap g

These ensure by parametricity:

dimap (f . g) (h . i) ≡ dimap g h . dimap f i
lmap (f . g) ≡ lmap g . lmap f
rmap (f . g) ≡ rmap f . rmap g

Laws:

unit . counit ≡ id
counit . unit ≡ id

Laws:

proextract . promap f ≡ f . proextract
proextract . produplicate ≡ id
promap proextract . produplicate ≡ id
produplicate . produplicate ≡ promap produplicate . produplicate