<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<!-- %% -->
<!-- %W  types.xml                 GAP manual                    Thomas Breuer -->
<!-- %W                                                       Martin Schönert -->
<!-- %% -->
<!-- %% -->

<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<Chapter Label="Types of Objects">
<Heading>Types of Objects</Heading>

Every &GAP; object has a <E>type</E>. The type of an object is the
information which is used to decide whether an operation is admissible
or possible with that object as an argument, and if so, how it is to
be performed
(see Chapter&nbsp;<Ref Chap="Method Selection"/>).
<P/>
For example, the types determine whether two objects can be multiplied
and what function is called to compute the product.  Analogously, the
type of an object determines whether and how the size of the object
can be computed. It is sometimes useful in discussing the type system,
to identify types with the set of objects that have this type. Partial
types can then also be regarded as sets, such that any type is the
intersection of its parts.
<P/>
The type of an object consists of two main parts, which describe
different aspects of the object.
<P/>
The <E>family</E> determines the relation of the object to other objects.
For example, all permutations form a family.  Another family consists
of all collections of permutations, this family contains the set of
permutation groups as a subset.  A third family consists of all
rational functions with coefficients in a certain family.
<P/>
The other part of a type is a collection of <E>filters</E> (actually stored
as a bit-list indicating, from the complete set of possible filters,
which are included in this particular type). These filters are all
treated equally by the method selection, but, from the viewpoint of
their creation and use, they can be divided (with a small number of
unimportant exceptions) into categories, representations, attribute
testers and properties. Each of these is described in more detail below.
<P/>
This chapter does not describe how types and their constituent parts
can be created.  Information about this topic can be found in
Chapter&nbsp;<Ref Chap="Creating New Objects"/>.
<P/>
<E>Note:</E> Detailed understanding of the type system is not
required to use &GAP;. It can be helpful, however, to understand how things
work and why &GAP; behaves the way it does.
<P/>
<!-- %%  The type system of &GAP; was devised by Thomas Breuer, Frank Celler, Steve -->
<!-- %%  Linton and Martin Schönert, -->
A discussion of the type system can be found in <Cite Key="BreuerLinton98"/>.


<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<Section Label="Families">
<Heading>Families</Heading>

The family of an object determines its relationship to other objects.
<P/>
More precisely, the families form a partition of all &GAP; objects
such that the following two conditions hold: objects that are equal
w.r.t. <C>=</C> lie in the same family; and the family of the result of
an operation depends only on the families of its operands.
<P/>
The first condition means that a family can be regarded as a set of
elements instead of a set of objects.  Note that this does not hold
for categories and representations (see below), two objects that are
equal w.r.t. <C>=</C> need not lie in the same categories and
representations.  For example, a sparsely represented matrix can be
equal to a densely represented matrix.  Similarly, each domain is
equal w.r.t. <C>=</C> to the sorted list of its elements, but a domain
is not a list, and a list is not a domain.
<P/>
Families are probably the least obvious part of the &GAP; type system,
so some remarks about the role of families are necessary.
When one uses &GAP; as it is, one will (better: should) not meet
families at all.
The two situations where families come into play are the following.
<P/>
First, since families are used to describe relations between arguments of
operations in the method selection mechanism
(see Chapter&nbsp;<Ref Chap="Method Selection"/>,
and also Chapter&nbsp;<Ref Chap="Types of Objects"/>),
one has to prescribe such a relation in each method installation
(see&nbsp;<Ref Sect="Method Installation"/>);
usual relations are <Ref Func="ReturnTrue"/>
(which means that any relation of the actual arguments is admissible),
<Ref Func="IsIdenticalObj"/> (which means that
there are two arguments that lie in the same family),
and <C>IsCollsElms</C>
(which means that there are two arguments,
the first being a collection of elements that lie in the same family
as the second argument).
<P/>
Second &ndash;and this is the more complicated situation&ndash;
whenever one creates a new kind of objects,
one has to decide what its family shall be.
If the new object shall be equal to existing objects,
for example if it is just represented in a different way,
there is no choice:
The new object must lie in the same family as all objects
that shall be equal to it.
So only if the new object is different
(w.r.t.&nbsp;the equality <Q><C>=</C></Q>)
from all other &GAP; objects, we are likely to create a new family
for it.
Note that enlarging an existing family by such new objects
may be problematic because of implications that have been
installed for all  objects of the family in question.
The choice of families depends on the applications one has in mind.
For example, if the new objects in question are not likely to be
arguments of operations for which family relations are relevant
(for example binary arithmetic operations),
one could create one family for all such objects,
and regard it as <Q>the family of all those &GAP; objects that would
in fact not need a family</Q>.
On the other extreme, if one wants to create domains of the new objects
then one has to choose the family in such a way that all intended
elements of a domain do in fact lie in the same family.
(Remember that a domain is a collection,
see Chapter&nbsp;<Ref Sect="Domains"/>,
and that a collection consists of elements in the same family,
see Chapter&nbsp;<Ref Chap="Collections"/>
and Section&nbsp;<Ref Sect="Families"/>.)
<P/>
Let us look at an example.
Suppose that no permutations are available in &GAP;,
and that we want to implement permutations.
Clearly we want to support permutation groups,
but it is not a priori clear how to distribute the new permutations
into families.
We can put all permutations into one family;
this is how in fact permutations are implemented in &GAP;.
But it would also be possible to put all permutations of a given degree
into a family of their own;
this would for example mean that for each degree,
there would be distinguished trivial permutations,
and that the stabilizer of the point <C>5</C> in the symmetric group on the
points <C>1</C>, <C>2</C>, <M>\ldots</M>, <C>5</C> is not regarded as equal to the
symmetric group on <C>1</C>, <C>2</C>, <C>3</C>, <C>4</C>.
Note that the latter approach would have the advantage that it is
no problem to construct permutations and permutation groups acting on
arbitrary (finite) sets,
for example by constructing first the symmetric group on the set
and then generating any desired permutation group as a subgroup of this
symmetric group.
<P/>
So one aspect concerning a reasonable choice of families is
to make the families large enough for being able to form interesting
domains of elements in the family.
But on the other hand,
it is useful to choose the families small enough for admitting
meaningful relations between objects.
For example, the elements of different free groups in &GAP;
lie in different families;
the multiplication of free group elements is installed only for the
case that the two operands lie in the same family,
with the effect that one cannot erroneously form the product of
elements from different free groups.
In this case, families appear as a tool for providing useful
restrictions.
<P/>
As another example, note that an element and a collection containing
this element never lie in the same family,
by the general implementation of collections;
namely, the family of a collection of elements in the family <A>Fam</A>
is the collections family of <A>Fam</A> (see&nbsp;<Ref Attr="CollectionsFamily"/>).
This means that for a collection, we need not (because we cannot)
decide about its family.
<P/>
A few functions in &GAP; return families,
see <Ref Attr="CollectionsFamily"/> and <Ref Attr="ElementsFamily"/>.

<#Include Label="FamilyObj">
<#Include Label="NewFamily">

</Section>


<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<Section Label="Filters">
<Heading>Filters</Heading>

A <E>filter</E> is a special unary &GAP; function that returns either <K>true</K>
or <K>false</K>, depending on whether or not the argument lies in the set defined
by the filter.
Filters are used to express different aspects of information about a &GAP;
object, which are described below
(see&nbsp;<Ref Sect="Categories"/>, <Ref Sect="Representation"/>, <Ref Sect="Attributes"/>,
<Ref Sect="Setter and Tester for Attributes"/>, <Ref Sect="Properties"/>, <Ref Sect="Other Filters"/>).
<P/>
Presently any filter in &GAP; is implemented as a function which
corresponds to a set of positions in the bitlist which forms part of the
type of each &GAP; object, and returns <K>true</K> if and only if the bitlist
of the type of the argument has the value <K>true</K> at all of these positions.
<P/>
The intersection (or meet) of two filters <A>filt1</A>, <A>filt2</A> is again a
filter, it can be formed as
<P/>
<Index Key="and" Subkey="for filters"><K>and</K></Index>
<A>filt1</A> <K>and</K> <A>filt2</A>
<P/>
See <Ref Sect="Operations for Booleans"/> for more details.
<P/>
For example, <C>IsList and IsEmpty</C> is a filter that returns <K>true</K> if
its argument is an empty list, and <K>false</K> otherwise.
The filter <Ref Filt="IsGroup"/> is defined as the intersection of
the category <Ref Filt="IsMagmaWithInverses"/>
and the property <Ref Prop="IsAssociative"/>.
<P/>
A filter that is not the meet of other filters is called a <E>simple
filter</E>.
For example, each attribute tester (see&nbsp;<Ref Sect="Setter and Tester for Attributes"/>)
is a simple filter.
Each simple filter corresponds to a position in the bitlist currently
used as part of the data structure representing a type.
<P/>
Every filter has a <E>rank</E>,
which is used to define a ranking of the methods installed for an operation,
see Section&nbsp;<Ref Sect="Method Installation"/>.
The rank of a filter can be accessed with <Ref Func="RankFilter"/>.

<ManSection>
<Func Name="RankFilter" Arg='filt'/>

<Description>
For simple filters, an <E>incremental rank</E> is defined when the filter is
created, see the sections about the creation of filters:
<Ref Func="NewCategory"/>,
<Ref Func="NewRepresentation"/>,
<Ref Func="NewAttribute"/>,
<Ref Func="NewProperty"/>,
<Ref Func="NewFilter"/>.
For an arbitrary filter, its rank is given by the sum of the incremental
ranks of the <E>involved</E> simple filters;
in addition to the implied filters, these are also the required filters
of attributes (again see the sections about the creation of filters).
In other words, for the purpose of computing the rank and <E>only</E> for this
purpose, attribute testers are treated as if they would imply the
requirements of their attributes.
<!-- % say something about the implementation via <C>InstallHiddenTrueMethod</C>? -->
</Description>
</ManSection>

<ManSection>
<Func Name="NamesFilter" Arg='filt'/>

<Description>
<Ref Func="NamesFilter"/> returns a list of names of the <E>implied</E>
simple filters of the filter <A>filt</A>,
these are all those simple filters <C>imp</C> such that every object in
<A>filt</A> also lies in <C>imp</C>.
For implications between filters, see <Ref Func="ShowImpliedFilters"/>
as well as sections&nbsp;<Ref Sect="Logical Implications"/>,
<Ref Func="NewCategory"/>,
<Ref Func="NewRepresentation"/>,
<Ref Func="NewAttribute"/>,
<Ref Func="NewProperty"/>.
</Description>
</ManSection>

<#Include Label="FilterByName">
<#Include Label="ShowImpliedFilters">
<#Include Label="FiltersType">

</Section>


<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<Section Label="Categories">
<Heading>Categories</Heading>

The <E>categories</E> of an object are filters (see&nbsp;<Ref Sect="Filters"/>)
that determine what operations an object admits.
For example, all integers form a category, all rationals form a category,
and all rational functions form a category.
An object which claims to lie in a certain category is accepting the
requirement that it should have methods for certain operations (and
perhaps that their behaviour should satisfy certain axioms).
For example, an object lying in the category <Ref Filt="IsList"/> must have
methods for <Ref Attr="Length"/>, <Ref Oper="IsBound\[\]"/>
and the list element access operation <Ref Oper="\[\]"/>.
<P/>
An object can lie in several categories.  For example, a row vector
lies in the categories <Ref Filt="IsList"/> and <Ref Filt="IsVector"/>;
each list lies in the category <Ref Filt="IsCopyable"/>,
and depending on whether or not it is mutable,
it may lie in the category <Ref Filt="IsMutable"/>.
Every domain lies in the category <Ref Filt="IsDomain"/>.
<P/>
Of course some categories of a mutable object may change when the
object is changed.  For example, after assigning values to positions
of a mutable non-dense list, this list may become part of the category
<Ref Filt="IsDenseList"/>.
<P/>
However, if an object is immutable then the set of categories it lies
in is fixed.
<P/>
All categories in the library are created during initialization, in
particular they are not created dynamically at runtime.
<P/>
The following list gives an overview of important categories of
arithmetic objects.  Indented categories are to be understood as
subcategories of the non indented category listed above it.
<Log><![CDATA[
    IsObject
        IsExtLElement
        IsExtRElement
            IsMultiplicativeElement
                IsMultiplicativeElementWithOne
                    IsMultiplicativeElementWithInverse
        IsExtAElement
            IsAdditiveElement
                IsAdditiveElementWithZero
                    IsAdditiveElementWithInverse
]]></Log>
Every object lies in the category <Ref Filt="IsObject"/>.
<P/>
The categories <Ref Filt="IsExtLElement"/> and <Ref Filt="IsExtRElement"/>
contain objects that can be multiplied with other objects via <C>*</C> from
the left and from the right, respectively. These categories are required
for the operands of the operation <C>*</C>.
<P/>
The category <Ref Filt="IsMultiplicativeElement"/> contains objects that
can be multiplied from the left and from the right with objects from the
same family. <Ref Filt="IsMultiplicativeElementWithOne"/> contains objects
<C>obj</C> for which a multiplicatively neutral element can be obtained by
taking the <M>0</M>-th power <C>obj^0</C>.
<Ref Filt="IsMultiplicativeElementWithInverse"/> contains objects
<C>obj</C> for which a multiplicative inverse can be obtained by
forming <C>obj^-1</C>.
<P/>
Likewise, the categories <Ref Filt="IsExtAElement"/>,
<Ref Filt="IsAdditiveElement"/>, <Ref Filt="IsAdditiveElementWithZero"/>
and <Ref Filt="IsAdditiveElementWithInverse"/>
contain objects that can be added via <C>+</C> to other objects, objects
that can be added to objects of the same family, objects for which an
additively neutral element can be obtained by multiplication with
zero, and objects for which an additive inverse can be obtained by
multiplication with <C>-1</C>.
<P/>
So a vector lies in <Ref Filt="IsExtLElement"/>, <Ref Filt="IsExtRElement"/>
and <Ref Filt="IsAdditiveElementWithInverse"/>. A ring element must
additionally lie in <Ref Filt="IsMultiplicativeElement"/>.
<P/>
As stated above it is not guaranteed by the categories of objects
whether the result of an operation with these objects as arguments is
defined.  For example, the category <Ref Filt="IsMatrix"/> is a subcategory
of <Ref Filt="IsMultiplicativeElementWithInverse"/>. Clearly not every
matrix has a multiplicative inverse. But the category <Ref Filt="IsMatrix"/>
makes each matrix an admissible argument of the operation
<Ref Attr="Inverse"/>, which may sometimes return <K>fail</K>.
Likewise, two matrices can be multiplied only if they are of appropriate
shapes.
<P/>
Analogous to the categories of arithmetic elements, there are
categories of domains of these elements.
<Log><![CDATA[
    IsObject
        IsDomain
            IsMagma
                IsMagmaWithOne
                    IsMagmaWithInversesIfNonzero
                        IsMagmaWithInverses
            IsAdditiveMagma
                IsAdditiveMagmaWithZero
                    IsAdditiveMagmaWithInverses
            IsExtLSet
            IsExtRSet
]]></Log>
Of course <Ref Filt="IsDomain"/> is a subcategory of <Ref Filt="IsObject"/>.
A domain that is
closed under multiplication <C>*</C> is called a magma and it lies in the
category <Ref Filt="IsMagma"/>.
If a magma is closed under taking the identity,
it lies in <Ref Filt="IsMagmaWithOne"/>, and if it is also closed under
taking inverses, it lies in <Ref Filt="IsMagmaWithInverses"/>. The category
<Ref Filt="IsMagmaWithInversesIfNonzero"/> denotes closure under taking
inverses only for nonzero elements, every division ring lies in this category.
<P/>
Note that every set of categories constitutes its own notion of
generation, for example a group may be generated as a magma with
inverses by some elements, but to generate it as a magma with one it
may be necessary to take the union of these generators and their
inverses.

<#Include Label="IsCategory">
<#Include Label="CategoriesOfObject">
<#Include Label="CategoryByName">

<#Include Label="NewCategory">
<#Include Label="DeclareCategory">
<#Include Label="CategoryFamily">

<P/>

See also <Ref Func="CategoryCollections"/>.

</Section>


<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<Section Label="Representation">
<Heading>Representation</Heading>

The <E>representation</E> of an object is a set of filters (see&nbsp;<Ref Sect="Filters"/>)
that determines how an object is actually represented.
For example, a matrix or a polynomial can be stored sparsely or
densely; all dense polynomials form a representation. An object which
claims to lie in a certain representation is accepting the requirement
that certain fields in the data structure be present and have
specified meanings.

<#Include Label="BasicRepresentations">
<#Include Label="IsRepresentation">
<#Include Label="RepresentationsOfObject">
<#Include Label="NewRepresentation">
<#Include Label="DeclareRepresentation">

</Section>


<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<Section Label="Attributes">
<Heading>Attributes</Heading>

The attributes of an object describe knowledge about it.
<P/>
An attribute is a unary operation without side-effects.
<P/>
An object may store values of its attributes once they have been
computed, and claim that it knows these values.  Note that <Q>store</Q>
and <Q>know</Q> have to be understood in the sense that it is very cheap
to get such a value when the attribute is called again.
<P/>
The value returned by an attribute is in general immutable
(see&nbsp;<Ref Sect="Mutability and Copyability"/>),
except if the attribute had been specially constructed as
<Q>mutable attribute</Q>, see <Ref Func="NewAttribute"/>.
<P/>
Note that functions installed as methods for attributes may return mutable
objects,
the attribute returns the value of <Ref Func="Immutable"/> for the result.
Thus it is recommended that these methods ensure their return values are
immutable, e.g., by calling <Ref Func="MakeImmutable"/> if this is possible,
in order to avoid that <Ref Func="Immutable"/> creates an unnecessary copy
of the object.
<P/>
It depends on the representation of an object (see&nbsp;<Ref Sect="Representation"/>)
which attribute values it stores.
An immutable object in the representation <Ref Filt="IsAttributeStoringRep"/>
stores <E>all</E> attribute values once they are computed.
<P/>
Note that it is impossible to get rid of a stored attribute
value because the system may have drawn conclusions from the old
attribute value, and just removing the value might leave the data
structures in an inconsistent state. If necessary, a new object can be
constructed.
<P/>
Each method that is installed for an attribute via <Ref Func="InstallMethod"/>
must require exactly one argument, and this must lie in the filter
<A>filter</A> that was entered as second argument of <Ref Func="NewAttribute"/>
resp. <Ref Func="NewProperty"/>.
<P/>
As for any operation, for attributes one can install a method taking an
argument that does not lie in <A>filt</A> via <Ref Func="InstallOtherMethod"/>,
or a method for more than one argument. For example,
<Ref Oper="IsTransitive" Label="for a group, an action domain, etc."/>
is an attribute for a <M>G</M>-set that
can also be called for the two arguments, being a group <M>G</M> and its action
domain.  If attributes are called with more than one argument then the
return value is not stored in any of the arguments.
<P/>
Properties are a special form of attributes that have the value <K>true</K>
or <K>false</K>, see section&nbsp;<Ref Sect="Properties"/>.
<P/>
Examples of attributes for multiplicative elements are
<Ref Attr="Inverse"/>, <Ref Attr="One"/>,
and <Ref Attr="Order"/>.
<Ref Attr="Size"/> is an attribute for domains,
<Ref Attr="Centre"/> is an attribute for magmas,
and <Ref Attr="DerivedSubgroup"/> is an attribute for groups.

<#Include Label="IsAttribute">
<#Include Label="KnownAttributesOfObject">
<#Include Label="NewAttribute">
<#Include Label="DeclareAttribute">
<#Include Label="IsAttributeStoringRep">

</Section>


<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<Section Label="Setter and Tester for Attributes">
<Heading>Setter and Tester for Attributes</Heading>

<Index>setter</Index>
<Index>tester</Index>
For every attribute, the <E>attribute setter</E>
and the <E>attribute tester</E> are defined.
<P/>
To check whether an object belongs to an attribute <A>attr</A>,
the tester of the attribute is used, see <Ref Func="Tester"/>.
To store a value for the attribute <A>attr</A> in an object,
the setter of the attribute is used, see <Ref Func="Setter"/>.


<ManSection>
<Func Name="Tester" Arg='attr'/>

<Description>
For an attribute <A>attr</A>, <C>Tester(<A>attr</A>)</C>
is a filter (see&nbsp;<Ref Sect="Filters"/>)
that returns <K>true</K> or <K>false</K>,
depending on whether or not the value of <A>attr</A> for the object is known.
For example, <C>Tester( Size )( <A>obj</A> )</C> is <K>true</K> if the size
of the object <A>obj</A> is known.
</Description>
</ManSection>

<ManSection>
<Func Name="Setter" Arg='attr'/>

<Description>
For an attribute <A>attr</A>, <C>Setter(<A>attr</A>)</C>
is called automatically when the attribute value has been
computed for an immutable object which does not already have a
value stored for <A>attr</A>.
One can also call the setter explicitly,
for example, <C>Setter( Size )( <A>obj</A>, <A>val</A> )</C>
sets <A>val</A> as size of the
object <A>obj</A> if the size was not yet known.
<P/>
For each attribute <A>attr</A> that is declared with
<Ref Func="DeclareAttribute"/> resp.&nbsp;<Ref Func="DeclareProperty"/>,
tester and setter are automatically made accessible by the names
<C>Has<A>attr</A></C> and <C>Set<A>attr</A></C>, respectively.
For example, the tester for <Ref Attr="Size"/> is called <C>HasSize</C>,
and the setter is called <C>SetSize</C>.
<P/>
<Example><![CDATA[
gap> g:=Group((1,2,3,4),(1,2));;Size(g);
24
gap> HasSize(g);
true
gap> SetSize(g,99);
gap> Size(g);
24
]]></Example>
<P/>
For two properties <A>prop1</A> and <A>prop2</A>,
the intersection <C><A>prop1</A> and <A>prop2</A></C> (see&nbsp;<Ref Sect="Filters"/>) is again a property
for which a setter and a tester exist.
Setting the value of this intersection to <K>true</K> for a &GAP; object
means to set the values of <A>prop1</A> and <A>prop2</A> to <K>true</K> for this object.
<P/>
<Example><![CDATA[
gap> prop:= IsFinite and IsCommutative;
<Property "(IsFinite and IsCommutative)">
gap> g:= Group( (1,2,3), (4,5) );;
gap> Tester( prop )( g );
false
gap> Setter( prop )( g, true );
gap> Tester( prop )( g );  prop( g );
true
true
]]></Example>
<P/>
It is <E>not allowed</E> to set the value of such an intersection to <K>false</K>
for an object.
<P/>
<Log><![CDATA[
gap> Setter( prop )( Rationals, false );
You cannot set an "and-filter" except to true
not in any function
Entering break read-eval-print loop ...
you can 'quit;' to quit to outer loop, or
you can type 'return true;' to set all components true
(but you might really want to reset just one component) to continue
brk>
]]></Log>
</Description>
</ManSection>


<ManSection>
<Func Name="AttributeValueNotSet" Arg='attr, obj'/>

<Description>
If the value of the attribute <A>attr</A> is already stored for <A>obj</A>,
<Ref Func="AttributeValueNotSet"/> simply returns this value.
Otherwise the value of <C><A>attr</A>( <A>obj</A> )</C> is computed and returned
<E>without storing it</E> in <A>obj</A>.
This can be useful when <Q>large</Q> attribute values (such as element lists)
are needed only once and shall not be stored in the object.
<P/>
<Example><![CDATA[
gap> HasAsSSortedList(g);
false
gap> AttributeValueNotSet(AsSSortedList,g);
[ (), (4,5), (1,2,3), (1,2,3)(4,5), (1,3,2), (1,3,2)(4,5) ]
gap> HasAsSSortedList(g);
false
]]></Example>
<P/>
<#Include Label="[1]{attr}">
</Description>
</ManSection>

<#Include Label="InfoAttributes">
<#Include Label="DisableAttributeValueStoring">
<#Include Label="EnableAttributeValueStoring">

</Section>


<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<Section Label="Properties">
<Heading>Properties</Heading>

The properties of an object are those of its attributes (see&nbsp;<Ref Sect="Attributes"/>)
whose values can only be <K>true</K> or <K>false</K>.
<P/>
The main difference between attributes and properties is that a
property defines two sets of objects, namely the usual set of all
objects for which the value is known, and the set of all objects for
which the value is known to be <K>true</K>.
<P/>
(Note that it makes no sense to consider a third set, namely the set
of objects for which the value of a property is <K>true</K> whether or not
it is known, since there may be objects for which the containment in
this set cannot be decided.)
<P/>
For a property <A>prop</A>, the containment of an object <A>obj</A> in the first
set is checked again by applying <C>Tester( <A>prop</A> )</C> to <A>obj</A>,
and <A>obj</A> lies in the second set if and only if
<C>Tester( <A>prop</A> )( <A>obj</A> ) and <A>prop</A>( <A>obj</A> )</C> is <K>true</K>.
<P/>
If a property value is known for an immutable object then this value is
also stored, as part of the type of the object.
To some extent, property values of mutable objects also can be stored,
for example a mutable list all of whose entries are immutable can store
whether it is strictly sorted. When the object is mutated (for example
by list assignment) the type may need to be adjusted.
<P/>
Important properties for domains are <Ref Prop="IsAssociative"/>,
<Ref Prop="IsCommutative"/>, <Ref Prop="IsAnticommutative"/>,
<Ref Prop="IsLDistributive"/> and <Ref Prop="IsRDistributive"/>,
which mean that the multiplication of elements in the domain satisfies
<M>( a * b ) * c = a * ( b * c )</M>, <M>a * b = b * a</M>,
<M>a * b = - ( b * a )</M>, <M>a * ( b + c ) = a * b + a * c</M>,
and <M>( a + b ) * c = a * c + b * c</M>, respectively,
for all <M>a</M>, <M>b</M>, <M>c</M> in the domain.
<P/>
<#Include Label="IsProperty">
<#Include Label="KnownPropertiesOfObject">
<#Include Label="KnownTruePropertiesOfObject">
<#Include Label="NewProperty">
<#Include Label="DeclareProperty">

</Section>


<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<Section Label="Other Filters">
<Heading>Other Filters</Heading>

There are situations where one wants to express a kind of knowledge
that is based on some heuristic.
<P/>
For example, the filters (see&nbsp;<Ref Sect="Filters"/>)
<Ref Filt="CanEasilyTestMembership"/> and
<Ref Filt="CanEasilyComputePcgs"/> are defined in the &GAP; library.
Note that such filters do not correspond to a mathematical concept,
contrary to properties (see&nbsp;<Ref Sect="Properties"/>).
Also it need not be defined what <Q>easily</Q> means for an arbitrary &GAP;
object, and in this case one cannot compute the value for an arbitrary
&GAP; object.
In order to access this kind of knowledge as a part of the type of an object,
&GAP; provides filters for which the value is <K>false</K> by default,
and it is changed to <K>true</K> in certain situations,
either explicitly (for the given object) or via a logical implication
(see&nbsp;<Ref Sect="Logical Implications"/>)
from other filters.
<P/>
For example, a <K>true</K> value of <Ref Filt="CanEasilyComputePcgs"/>
for a group means that certain methods are applicable that use a pcgs
(see&nbsp;<Ref Sect="Polycyclic Generating Systems"/>) for the group.
There are logical implications to set the filter value to <K>true</K>
for permutation groups that are known to be solvable,
and for groups that have already a (sufficiently nice) pcgs stored.
In the case one has a solvable matrix group and wants to enable methods
that use a pcgs, one can set the <Ref Filt="CanEasilyComputePcgs"/>
value to <K>true</K> for this particular group.
<P/>
A filter <A>filt</A> of the kind described here is different from
the other filters introduced in the previous sections.
In particular, <A>filt</A> is not a category (see&nbsp;<Ref Sect="Categories"/>) or a property
(see&nbsp;<Ref Sect="Properties"/>) because its value may change for a given object,
and <A>filt</A> is not a representation (see&nbsp;<Ref Sect="Representation"/>) because it has
nothing to do with the way an object is made up from some data.
<A>filt</A> is similar to an attribute tester
(see&nbsp;<Ref Sect="Setter and Tester for Attributes"/>),
the only difference is that <A>filt</A> does not refer to an attribute value;
note that <A>filt</A> is also used in the same way as an attribute tester;
namely, the <K>true</K> value may be required for certain methods to be
applicable.
<P/>
In order to change the value of <A>filt</A> for an object <A>obj</A>,
one can use logical implications
(see&nbsp;<Ref Sect="Logical Implications"/>) or
<Ref Func="SetFilterObj"/>, <Ref Func="ResetFilterObj"/>.

<#Include Label="NewFilter">
<#Include Label="DeclareFilter">
<#Include Label="SetFilterObj">
<#Include Label="ResetFilterObj">

<!-- %T Categories and representations should not be operations, -->
<!-- %T the same for filters made by <C>NewFilter</C>! -->

</Section>


<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<Section Label="Types">
<Heading>Types</Heading>

We stated above (see <Ref Chap="Types of Objects"/>) that, for an object <A>obj</A>,
its <E>type</E> is formed from its family and its filters.  There is also
a third component, used in a few situations, namely defining data of
the type.

<#Include Label="TypeObj">

<ManSection>
<Func Name="DataType" Arg='type'/>

<Description>
The last part of the type, defining data, has not been mentioned
before and seems to be of minor importance.
It can be used, e.g., for cosets <M>U g</M> of a group <M>U</M>,
where the type of each coset may contain the group <M>U</M> as defining
data.
As a consequence, two such cosets mod <M>U</M> and <M>V</M> can have the
same type only if <M>U = V</M>.
The defining data of the type <A>type</A> can be accessed via
<Ref Func="DataType"/>.
</Description>
</ManSection>

<#Include Label="NewType">

</Section>
</Chapter>


<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<!-- %% -->
<!-- %E -->