@Chapter Limits and Colimits

This section describes the support for limits and colimits in CAP. All notions defined in the following are considered with regard to limits, not colimits, except if explicitly stated otherwise. In particular, the diagram specification specifies a diagram over which the limit is taken. The colimit in turn is taken over the opposite diagram.

@Section Specification of Limits and Colimits

A record specifying a limit in CAP has the following entries:

* object_specification: see below

* morphism_specifiation: see below

* limit_object_name: the name of the method returning the limit object, e.g. <C>DirectProduct</C> or <C>KernelObject</C>

* limit_projection_name (optional): the name of the method returning the projection(s) from the limit object, e.g. <C>ProjectionInFactorOfDirectProduct</C> or <C>KernelEmbedding</C>. Defaults to <C>Concatenation( "ProjectionInFactorOf", limit_object_name )</C>.

* limit_universal_morphism_name (optional): the name of the method returning the universal morphism into the limit object, e.g. <C>UniversalMorphismIntoDirectProduct</C> or <C>KernelLift</C>. Defaults to <C>Concatenation( "UniversalMorphismInto", limit_object_name )</C>.

* colimit_object_name: the name of the method returning the colimit object, e.g. <C>Coproduct</C> or <C>CokernelObject</C>

* colimit_injection_name (optional): the name of the method returning the injection(s) into the colimit object, e.g. <C>InjectionOfCofactorOfCoproduct</C> or <C>CokernelProjection</C>. Defaults to <C>Concatenation( "InjectionOfCofactorOf", colimit_object_name )</C>.

* colimit_universal_morphism_name (optional): the name of the method returning the universal morphism from the colimit object, e.g. <C>UniversalMorphismFromCoproduct</C> or <C>CokernelColift</C>. Defaults to <C>Concatenation( "UniversalMorphismFrom", colimit_object_name )</C>.

limit_object_name and colimit_object_name can be the same, e.g. for <C>DirectSum</C> or <C>ZeroObject</C>.

The object_specification and morphism_specification together specify the shape of the diagram defining the limit or colimit. The syntax is the following:

* object_specification is a list of strings. Only the strings "fixedobject" and "varobject" are allowed as entries of the list. These are called "types" in the following.

* morphism_specification is a list of triples. The first and third entry of a triple are integers greater or equal to 1 and less or equal to <C>Length( object_specification )</C>. The second entry is one of the following strings: "fixedmorphism", "varmorphism", "zeromorphism". This entry is called "type" in the following.

Semantics is given as follows:

* The type "fixedobject" specifies a single object. The type "varobject" specifies arbitrarily many objects.
* The first and the third entry of a triple specify the source and range of a morphism (or multiple morphisms) encoded by the position in object_specification respectively. The type "fixedmorphism" specifies a single morphism. In this case, source and range can only be of type "fixedobject", not of type "varobject". The type "varmorphism" specifies arbitrarily many morphisms. In this case, if the source (resp. range) is of type "fixedobject" all the morphisms must have the same source (resp. range). On the contrary, if the source (resp. range) is of the type "varobject", the objects correspond one-to-one to the sources (resp. ranges) of the morphisms. The type "zeromorphism" is currently ignored but will be endowed with semantics in the future.

For example, a FiberProduct diagram consists of arbitrarily many morphisms which have arbitrary sources but the same common range. This can be expressed as follows:

@BeginCode example_limit_record
rec(
  object_specification := [ "fixedobject", "varobject" ],
  morphism_specification := [ [ 2, "varmorphism", 1 ] ],
  limit_object_name := "FiberProduct",
  colimit_object_name := "Pushout",
)
@EndCode

@InsertCode example_limit_record

Note that not all diagrams which can be expressed with the above are actually supported. For now, at most one unbound object (see below for the definition of "unbound") may be of type "varobject", and if there is such an unbound object it must be the last one among the unbound objects. Similarly, at most one unbound morphism may be of type "varmorphism", and if there is such an unbound morphism it must be the last one among the unbound morphisms.

@Section Enhancing Limit Specifications

The function CAP_INTERNAL_ENHANCE_NAME_RECORD_LIMITS takes a list of limits (given by records as explained above), and computes some additional properties. For example, the number of so-called unbound objects, unbound morphisms and (non-)targets is computed. The term "unbound" signifies that for creating a concrete diagram, these objects or morphisms have to be specified by the user because they cannot be derived by CAP:

* Unbound morphisms are the triples which are of type "fixedmorphism" or "varmorphism".
* Unbound objects are the objects which are not source or range of an unbound morphism.

Finally, targets are the objects which are not the range of a morphism. These are of interest for the following reason: for limits, only projections into targets are relevant because the projections into other objects can simply be computed by composition. Similarly, one only has to give morphisms into these targets to compute a universal morphism.

The number of unbound objects, unbound morphisms and (non-)targets is expressed by the integers 0, 1 and 2:

* 0: no such object/morphism/target exists

* 1: there exists exactly one such object/target of type "fixedobject" respectively exactly one such morphism of type "fixedmorphism"

* 2: else

@Section Functions

