const package:constrained-categories

const x is a unary function which evaluates to x for all inputs.

>>> const 42 "hello"
42

>>> map (const 42) [0..3]
[42,42,42,42]

Constrained clones of the category-theory type classes, using ConstraintKinds. Haskell has, and makes great use of, powerful facilities from category theory – basically various variants of functors. However, all those are just endofunctors in Hask, the category of all Haskell types with functions as morphisms. Which is sufficient for container / control structures that you want to be able to handle any type of data, but otherwise it's a bit limiting, seeing as there are (in maths, science etc.) many categories that cannot properly be represented this way. Commonly used libraries such as http://hackage.haskell.org/package/vector-space thus make little notion of the fact that the objects they deal with actually form a category, instead defining just specialised versions of the operations. This library generalises functors etc. to a much wider class of categories, by allowing for constraints on objects (so these can have extra properties required). At the same time, we try to keep as close as possible to the well-known Haskell type class hierarchies rather than exactly adopting the mathematicians' notions. Consider the README file, the examples, and/or the documentation to Control.Category.Constrained for how to make use of this.

Cast a morphism to its equivalent in a more constrained category, provided it connects objects that actually satisfy the extra constraint. In practice, it is often necessary to specify to what typeclass it should be constrained. The most convenient way of doing that is with type-applications syntax. E.g. constrained @Ord length is the length function considered as a morphism in the subcategory of Hask in which all types are orderable. (Which makes it suitable for e.g. fmapping over a set.)

Haskell's Arrows, going back to [Hughes 2000], combine multiple ideas from category theory:

• They expand upon cartesian categories, by offering ways to combine arrows between simple objects to composite ones working on tuples (i.e. products) thereof.
• They constitute a "profunctor" interface, allowing to "fmap" both covariantly over the second parameter, as well as contravariantly over the first. As in case of Control.Functor.Constrained, we wish the underlying category to fmap from not to be limited to Hask, so Arrow also has an extra parameter.

To facilitate these somewhat divergent needs, Arrow is split up in three classes. These do not even form an ordinary hierarchy, to allow categories to implement only one or the other aspect. That's not the only significant difference of this module, compared to Control.Arrow:

• Kleisli arrows are not defined here, but in Control.Monad.Constrained. Monads are really a much more specific concept than category arrows.
• Some extra utilities are included that don't apparently have much to do with Arrow at all, but require the expanded cartesian-category tools and are therefore not in Control.Category.Constrained.

The most basic category theory tools are included partly in this module, partly in Control.Arrow.Constrained.

A given category can be specialised, by using the same morphisms but adding extra constraints to what is considered an object. For instance, Ord⊢(->) is the category of all totally ordered data types (but with arbitrary functions; this does not require monotonicity or anything).

A given category can be specialised, by using the same morphisms but adding extra constraints to what is considered an object. For instance, Ord⊢(->) is the category of all totally ordered data types (but with arbitrary functions; this does not require monotonicity or anything).

"Unpack" a constrained morphism again (forgetful functor). Note that you may often not need to do that; in particular morphisms that are actually Functions can just be applied to their objects with $ right away, no need to go back to Hask first.