<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<!-- %% -->
<!-- %A  create.tex                GAP manual                    Thomas Breuer -->
<!-- %A                                                       Martin Schönert -->
<!-- %% -->
<!-- %H  @(#)<M>Id: create.tex,v 4.48 2005/10/20 07:39:10 gap Exp </M> -->
<!-- %% -->

<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<Chapter Label="Creating New Objects">
<Heading>Creating New Objects</Heading>

This chapter is divided into three parts.
<P/>
In the first part, it is explained how to create
filters (see&nbsp;<Ref Sect="Creating Categories"/>, <Ref Sect="Creating Representations"/>,
<Ref Sect="Creating Attributes and Properties"/>, <Ref Sect="Creating Other Filters"/>),
operations (see&nbsp;<Ref Sect="Creating Operations"/>),
families (see&nbsp;<Ref Sect="Creating Families"/>),
types (see&nbsp;<Ref Sect="Creating Types"/>),
and objects with given type (see&nbsp;<Ref Sect="Creating Objects"/>).
<P/>
In the second part, first a few small examples are given,
for dealing with the usual cases of
component objects (see&nbsp;<Ref Sect="Component Objects"/>)
and positional objects (see&nbsp;<Ref Sect="Positional Objects"/>),
and for the implementation of new kinds of lists
(see&nbsp;<Ref Sect="Implementing New List Objects"/>
and&nbsp;<Ref Sect="Arithmetic Issues in the Implementation of New Kinds of Lists"/>).
Finally, the external representation of objects is introduced
(see&nbsp;<Ref Sect="External Representation"/>),
as a tool for representation independent access to an object.
<P/>
The third part deals with some rules concerning the organization
of the &GAP; library;
namely, some commands for creating global variables are explained
(see&nbsp;<Ref Sect="Global Variables in the Library"/>)
that correspond to the ones discussed in the first part of the chapter,
and the idea of distinguishing declaration and implementation part
of &GAP; packages is outlined (see&nbsp;<Ref Sect="Declaration and Implementation Part"/>).
<P/>
See also Chapter&nbsp;<Ref Chap="An Example -- Residue Class Rings"/> for examples
how the functions from the first part are used,
and why it is useful to have a declaration part and an implementation part.


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

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

<P/>

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

</Section>


<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<Section Label="Creating Representations">
<Heading>Creating Representations</Heading>

<#Include Label="NewRepresentation">

</Section>


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

Each method that is installed for an attribute or a property
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 (see&nbsp;<Ref Sect="Creating Operations"/>),
for attributes and properties 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;
in the latter case,
clearly the result value is <E>not</E> stored in any of the arguments.

<#Include Label="NewAttribute">
<#Include Label="NewProperty">

</Section>


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

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="SetFilterObj">
<#Include Label="ResetFilterObj">

<!-- %T Categories and representations should not be operations, -->
<!-- %T the same for filters made by <C>NewFilter</C>! -->
<!-- %AK Now everything is displayed properly -->

</Section>


<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<Section Label="Creating Operations">
<Heading>Creating Operations</Heading>

<#Include Label="NewOperation">

</Section>

<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<Section Label="Creating Constructors">
<Heading>Creating Constructors</Heading>

<#Include Label="NewConstructor">

</Section>


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

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 Func="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 Func="CollectionsFamily"/> and <Ref Func="ElementsFamily"/>.

<#Include Label="NewFamily">

</Section>


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

<#Include Label="NewType">

</Section>


<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<Section Label="Creating Objects">
<Heading>Creating Objects</Heading>

<ManSection>
<Func Name="Objectify" Arg="type, data"/>

<Description>
New objects are created by <Ref Func="Objectify"/>.
<A>data</A> is a list or a record, and <A>type</A> is the type that the
desired object shall have.
<Ref Func="Objectify"/> turns <A>data</A> into an object with type
<A>type</A>.
That is, <A>data</A> is changed, and afterwards it will not be a list or a
record unless <A>type</A> is of type list resp. record.
<P/>
If <A>data</A> is a list then <Ref Func="Objectify"/> turns it into a
positional object, if <A>data</A> is a record then
<Ref Func="Objectify"/> turns it into a component object
(for examples, see&nbsp;<Ref Sect="Component Objects"/>
and&nbsp;<Ref Sect="Positional Objects"/>).
<P/>
<Ref Func="Objectify"/> does also return the object that it made out of
<A>data</A>.
<P/>
For examples where <Ref Func="Objectify"/> is used,
see&nbsp;<Ref Sect="Component Objects"/>,
<Ref Sect="Positional Objects"/>, and the example in
Chapter&nbsp;<Ref Chap="An Example -- Residue Class Rings"/>.
</Description>
</ManSection>

<#Include Label="ObjectifyWithAttributes">

</Section>


<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<Section Label="Component Objects">
<Heading>Component Objects</Heading>

A <E>component object</E> is an object in the representation
<C>IsComponentObjectRep</C> or a subrepresentation of it.
Such an object <A>cobj</A> is built from subobjects that can be accessed via
<C><A>cobj</A>!.<A>name</A></C>, similar to components of a record.
Also analogously to records, values can be assigned to components of
<A>cobj</A> via <C><A>cobj</A>!.<A>name</A>:= <A>val</A></C>.
For the creation of component objects, see&nbsp;<Ref Sect="Creating Objects"/>.

One must be <E>very careful</E> when using the <C>!.</C> operator,
in order to interpret the component in the right way,
and even more careful when using the assignment to components using <C>!.</C>,
in order to keep the information stored in <A>cobj</A> consistent.
<P/>
First of all, in the access or assignment to a component as shown above,
<A>name</A> must be among the admissible component names
for the representation of <A>cobj</A>, see&nbsp;<Ref Sect="Creating Representations"/>.
Second, preferably only few low level functions should use <C>!.</C>,
whereas this operator should not occur in <Q>user interactions</Q>.
<P/>
Note that even if <A>cobj</A> claims that it is immutable, i.e.,
if <A>cobj</A> is not in the category <Ref Func="IsMutable"/>,
access and assignment via <C>!.</C> and <C>!.:=</C> work.
This is necessary for being able to store newly discovered information
in immutable objects.
<P/>
The following example shows the implementation of an iterator
(see&nbsp;<Ref Sect="Iterators"/>) for the domain of integers,
which is represented as component object.
See&nbsp;<Ref Sect="Positional Objects"/> for an implementation using positional objects.
(In practice, such an iterator can be implemented more elegantly using
<Ref Func="IteratorByFunctions"/>,
see&nbsp;<Ref Sect="Example -- Constructing Iterators"/>.)
<P/>
The used succession of integers is <M>0, 1, -1, 2, -2, 3, -3, \ldots</M>,
that is, <M>a_n = n/2</M> if <M>n</M> is even,
and <M>a_n = (1-n)/2</M> otherwise.
<P/>
<Log><![CDATA[
IsIntegersIteratorCompRep := NewRepresentation( "IsIntegersIteratorRep",
    IsComponentObjectRep, [ "counter" ] );
]]></Log>
<P/>
The above command creates a new representation (see&nbsp;<Ref Func="NewRepresentation"/>)
<C>IsIntegersIteratorCompRep</C>,
as a subrepresentation of <C>IsComponentObjectRep</C>,
and with one admissible component <C>counter</C>.
So no other components than <C>counter</C> will be needed.
<P/>
<Log><![CDATA[
InstallMethod( Iterator,
    "method for `Integers'",
    [ IsIntegers ],
    function( Integers )
    return Objectify( NewType( IteratorsFamily,
                                   IsIterator
                               and IsIntegersIteratorCompRep ),
                      rec( counter := 0 ) );
    end );
]]></Log>
<P/>
After the above method installation, one can already ask for
<C>Iterator( Integers )</C>.
Note that exactly the domain of integers is described by
the filter <Ref Func="IsIntegers"/>.
<P/>
By the call to <Ref Func="NewType"/>, the returned object lies in the family
containing all iterators, which is <C>IteratorsFamily</C>,
it lies in the category <Ref Func="IsIterator"/>
and in the representation <C>IsIntegersIteratorCompRep</C>;
furthermore, it has the component <C>counter</C> with value <C>0</C>.
<P/>
What is missing now are methods for the two basic operations
of iterators, namely <Ref Func="IsDoneIterator"/> and
<Ref Func="NextIterator"/>.
The former must always return <K>false</K>, since there are infinitely
many integers.
The latter must return the next integer in the iteration,
and update the information stored in the iterator,
that is, increase the value of the component <C>counter</C>.
<P/>
<Log><![CDATA[
InstallMethod( IsDoneIterator,
    "method for iterator of `Integers'",
    [ IsIterator and IsIntegersIteratorCompRep ],
    ReturnFalse );

InstallMethod( NextIterator,
    "method for iterator of `Integers'",
    [ IsIntegersIteratorCompRep ],
    function( iter )
    iter!.counter:= iter!.counter + 1;
    if iter!.counter mod 2 = 0 then
      return iter!.counter / 2;
    else
      return ( 1 - iter!.counter ) / 2;
    fi;
    end );
]]></Log>

<#Include Label="NamesOfComponents">

</Section>


<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<Section Label="Positional Objects">
<Heading>Positional Objects</Heading>

A <E>positional object</E> is an object in the representation
<C>IsPositionalObjectRep</C> or a subrepresentation of it.
Such an object <A>pobj</A> is built from subobjects that can be accessed via
<C><A>pobj</A>![<A>pos</A>]</C>, similar to positions in a list.
Also analogously to lists, values can be assigned to positions of
<A>pobj</A> via <C><A>pobj</A>![<A>pos</A>]:= <A>val</A></C>.
For the creation of positional objects, see&nbsp;<Ref Sect="Creating Objects"/>.
<P/>
One must be <E>very careful</E> when using the <C>![]</C> operator,
in order to interpret the position in the right way,
and even more careful when using the assignment to positions using <C>![]</C>,
in order to keep the information stored in <A>pobj</A> consistent.
<P/>
First of all, in the access or assignment to a position as shown above,
<A>pos</A> must be among the admissible positions
for the representation of <A>pobj</A>, see&nbsp;<Ref Sect="Creating Representations"/>.
Second, preferably only few low level functions should use <C>![]</C>,
whereas this operator should not occur in <Q>user interactions</Q>.
<P/>
Note that even if <A>pobj</A> claims that it is immutable, i.e.,
if <A>pobj</A> is not in the category <Ref Func="IsMutable"/>,
access and assignment via <C>![]</C> work.
This is necessary for being able to store newly discovered information
in immutable objects.
<P/>
The following example shows the implementation of an iterator
(see&nbsp;<Ref Sect="Iterators"/>) for the domain of integers,
which is represented as positional object.
See&nbsp;<Ref Sect="Component Objects"/> for an implementation using component objects,
and more details.
<P/>
<Log><![CDATA[
IsIntegersIteratorPosRep := NewRepresentation( "IsIntegersIteratorRep",
    IsPositionalObjectRep, [ 1 ] );
]]></Log>
<P/>
The above command creates a new representation (see&nbsp;<Ref Func="NewRepresentation"/>)
<C>IsIntegersIteratorPosRep</C>,
as a subrepresentation of <C>IsComponentObjectRep</C>,
and with only the first position being admissible for storing data.
<P/>
<Log><![CDATA[
InstallMethod( Iterator,
    "method for `Integers'",
    [ IsIntegers ],
    function( Integers )
    return Objectify( NewType( IteratorsFamily,
                                   IsIterator
                               and IsIntegersIteratorRep ),
                      [ 0 ] );
    end );
]]></Log>
<P/>
After the above method installation, one can already ask for
<C>Iterator( Integers )</C>.
Note that exactly the domain of integers is described by
the filter <Ref Func="IsIntegers"/>.
<P/>
By the call to <Ref Func="NewType"/>, the returned object lies in the family
containing all iterators, which is <C>IteratorsFamily</C>,
it lies in the category <Ref Func="IsIterator"/>
and in the representation <C>IsIntegersIteratorPosRep</C>;
furthermore, the first position has value <C>0</C>.
<P/>
What is missing now are methods for the two basic operations
of iterators, namely <Ref Func="IsDoneIterator"/>
and <Ref Func="NextIterator"/>.
The former must always return <K>false</K>, since there are infinitely
many integers.
The latter must return the next integer in the iteration,
and update the information stored in the iterator,
that is, increase the value stored in the first position.
<P/>
<Log><![CDATA[
InstallMethod( IsDoneIterator,
    "method for iterator of `Integers'",
    [ IsIterator and IsIntegersIteratorPosRep ],
    ReturnFalse );

InstallMethod( NextIterator,
    "method for iterator of `Integers'",
    [ IsIntegersIteratorPosRep ],
    function( iter )
    iter![1]:= iter![1] + 1;
    if iter![1] mod 2 = 0 then
      return iter![1] / 2;
    else
      return ( 1 - iter![1] ) / 2;
    fi;
    end );
]]></Log>
<P/>
It should be noted that one can of course install both the methods shown
in Section&nbsp;<Ref Sect="Component Objects"/> and <Ref Sect="Positional Objects"/>.
The call <C>Iterator( Integers )</C> will cause one of the methods to be
selected, and for the returned iterator, which will have one of the
representations we constructed,
the right <Ref Func="NextIterator"/> method will be chosen.

</Section>


<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<Section Label="Implementing New List Objects">
<Heading>Implementing New List Objects</Heading>

This section gives some hints for the quite usual situation that one wants
to implement new objects that are lists.
More precisely, one either wants to deal with lists that have additional
features, or one wants that some objects also behave as lists.
An example can be found in&nbsp;<Ref Sect="Example -- Constructing Enumerators"/>.
<P/>
A <E>list</E> in &GAP; is an object in the category
<Ref Func="IsList"/>.
Basic operations for lists are <Ref Func="Length"/>,
<Ref Func="\[\]"/>,
and <Ref Func="IsBound\[\]"/>
(see&nbsp;<Ref Sect="Basic Operations for Lists"/>).
<P/>
Note that the access to the position <A>pos</A> in the list <A>list</A>
via <C><A>list</A>[<A>pos</A>]</C> is handled by the call
<C>\[\]( <A>list</A>, <A>pos</A> )</C>
to the operation <Ref Func="\[\]"/>.
To explain the somewhat strange name <C>\[\]</C> of this operation,
note that non-alphanumeric characters like <C>[</C> and <C>]</C> may occur in
&GAP; variable names only if they are escaped by a <C>\</C> character.
<P/>
Analogously, the check <C>IsBound( <A>list</A>[<A>pos</A>] )</C> whether the position
<A>pos</A> of the list <A>list</A> is bound is handled by the call
<C>IsBound\[\]( <A>list</A>, <A>pos</A> )</C> to the operation
<Ref Func="IsBound\[\]"/>.
<P/>
For mutable lists, also assignment to positions and unbinding of
positions via the operations <Ref Func="\[\]\:\="/>
and <Ref Func="Unbind\[\]"/>
are basic operations.
The assignment <C><A>list</A>[<A>pos</A>]:= <A>val</A></C>
is handled by the call
<C>\[\]\:\=( <A>list</A>, <A>pos</A>, <A>val</A> )</C>,
and <C>Unbind( <A>list</A>[<A>pos</A>] )</C> is handled by the call
<C>Unbind\[\]( <A>list</A>, <A>pos</A> )</C>.
<P/>
All other operations for lists, e.g., <Ref Func="Add"/>,
<Ref Func="Append"/>, <Ref Func="Sum"/>,
are based on these operations.
This means that it is sufficient to install methods for the new list
objects only for the basic operations.
<P/>
So if one wants to implement new list objects then one creates them
as objects in the category <Ref Func="IsList"/>,
and installs methods for <Ref Func="Length"/>,
<Ref Func="\[\]"/>,
and <Ref Func="IsBound\[\]"/>.
If the new lists shall be mutable, one needs to install also methods
for <Ref Func="\[\]\:\="/> and
<Ref Func="Unbind\[\]"/>.
<P/>
One application for this is the implementation of <E>enumerators</E>
for domains.
An enumerator for the domain <M>D</M> is a dense list whose entries are
in bijection with the elements of <M>D</M>.
If <M>D</M> is large then it is not useful to write down all elements.
Instead one can implement such a bijection implicitly.
This works also for infinite domains.
<P/>
In this situation, one implements a new representation of the
lists that are already available in &GAP;,
in particular the family of such a list is the same as the family of
the domain <M>D</M>.
<P/>
But it is also possible to implement new kinds of lists that lie in
new families, and thus are not equal to lists that were available
in &GAP; before.
An example for this is the implementation of matrices
whose multiplication via <Q><C>*</C></Q> is the Lie product of matrices.
<P/>
In this situation, it makes no sense to put the new matrices into the
same family as the original matrices.
Note that the product of two Lie matrices shall be defined but not the
product of an ordinary matrix and a Lie matrix.
So it is possible to have two lists that have the same entries but that
are not equal w.r.t. <Q><C>=</C></Q> because they lie in different families.

</Section>


<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<Section Label="Example -- Constructing Enumerators">
<Heading>Example &ndash; Constructing Enumerators</Heading>

When dealing with countable sets, a usual task is to define enumerations,
i.e., bijections to the positive integers.
In &GAP;, this can be implemented via <E>enumerators</E>
(see&nbsp;<Ref Sect="Enumerators"/>).
These are lists containing the elements in a specified ordering,
and the operations <Ref Func="Position"/>
and list access via <Ref Func="\[\]"/> define the
desired bijection.
For implementing such an enumerator, one mainly needs to install the
appropriate functions for these operations.
<P/>
A general setup for creating such lists is given by
<Ref Func="EnumeratorByFunctions" Label="for a domain and a record"/>.
<P/>
If the set in question is a domain <A>D</A> for which a
<Ref Func="Size"/> method is
available then all one has to do is to write down the functions for
computing the <M>n</M>-th element of the list and for computing the position
of a given &GAP; object in the list, to put them into the components
<C>ElementNumber</C> and <C>NumberElement</C> of a record, and to call
<Ref Func="EnumeratorByFunctions" Label="for a domain and a record"/>
with the domain <A>D</A> and this record as arguments.
For example, the following lines of code install an
<Ref Func="Enumerator"/> method
for the case that <A>D</A> is the domain of rational integers.
(Note that <Ref Func="IsIntegers"/> is a filter
that describes exactly the domain of rational integers.)
<P/>
<Log><![CDATA[
InstallMethod( Enumerator,
    "for integers",
    [ IsIntegers ],
    Integers -> EnumeratorByFunctions( Integers, rec(
                    ElementNumber := function( e, n ) ... end,
                    NumberElement := function( e, x ) ... end ) ) );
]]></Log>
<P/>
The bodies of the functions have been omitted above;
here is the code that is actually used in &GAP;.
(The ordering coincides with that for the iterators for the domain of
rational integers that have been discussed in&nbsp;<Ref Sect="Component Objects"/>
and&nbsp;<Ref Sect="Positional Objects"/>.)
<P/>
<Example><![CDATA[
gap> enum:= Enumerator( Integers );
<enumerator of Integers>
gap> Print( enum!.NumberElement, "\n" );
function ( e, x )
    local  pos;
    if not IsInt( x )  then
        return fail;
    elif 0 < x  then
        pos := 2 * x;
    else
        pos := -2 * x + 1;
    fi;
    return pos;
end
gap> Print( enum!.ElementNumber, "\n" );
function ( e, n )
    if n mod 2 = 0  then
        return n / 2;
    else
        return (1 - n) / 2;
    fi;
    return;
end
]]></Example>
<P/>
The situation becomes slightly more complicated if the set <M>S</M> in question
is not a domain.
This is because one must provide also at least a method for computing the
length of the list, and because one has to determine the family in which
it lies (see&nbsp;<Ref Sect="Creating Objects"/>).
The latter should usually not be a problem since either <M>S</M> is nonempty and
all its elements lie in the same family &ndash;in this case one takes the
collections family of any element in <M>S</M>&ndash; or the family of the enumerator
must be <C>ListsFamily</C>.
<P/>
An example in the &GAP; library is an enumerator for the set of <M>k</M>-tuples
over a finite set; the function is called
<Ref Func="EnumeratorOfTuples"/>.
<!-- % The functions <C>ExtendedVectors</C> and <C>OneDimSubspacesTransversal</C> are -->
<!-- % also examples but are currently also undocumented ... -->
<P/>
<Example><![CDATA[
gap> Print( EnumeratorOfTuples, "\n" );
function ( set, k )
    local  enum;
    if k = 0  then
        return Immutable( [ [  ] ] );
    elif IsEmpty( set )  then
        return Immutable( [  ] );
    fi;
    enum 
     := EnumeratorByFunctions( CollectionsFamily( FamilyObj( set ) ), 
       rec(
          ElementNumber := function ( enum, n )
                local  nn, t, i;
                nn := n - 1;
                t := [  ];
                for i  in [ 1 .. enum!.k ]  do
                    t[i] := RemInt( nn, Length( enum!.set ) ) + 1;
                    nn := QuoInt( nn, Length( enum!.set ) );
                od;
                if nn <> 0  then
                    Error( "<enum>[", n, 
                     "] must have an assigned value" );
                fi;
                nn := enum!.set{Reversed( t )};
                MakeImmutable( nn );
                return nn;
            end,
          NumberElement := function ( enum, elm )
                local  n, i;
                if not IsList( elm )  then
                    return fail;
                fi;
                elm := List( elm, function ( x )
                        return Position( enum!.set, x );
                    end );
                if fail in elm or Length( elm ) <> enum!.k  then
                    return fail;
                fi;
                n := 0;
                for i  in [ 1 .. enum!.k ]  do
                    n := Length( enum!.set ) * n + elm[i] - 1;
                od;
                return n + 1;
            end,
          Length := function ( enum )
                return Length( enum!.set ) ^ enum!.k;
            end,
          PrintObj := function ( enum )
                Print( "EnumeratorOfTuples( ", enum!.set, ", ", 
                 enum!.k, " )" );
                return;
            end,
          set := Set( set ),
          k := k ) );
    SetIsSSortedList( enum, true );
    return enum;
end
]]></Example>
<P/>
We see that the enumerator is a homogeneous list that stores individual
functions <C>ElementNumber</C>, <C>NumberElement</C>,
<C>Length</C>, and <C>PrintObj</C>;
besides that, the data components <M>S</M> and <M>k</M> are contained.

</Section>


<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<Section Label="Example -- Constructing Iterators">
<Heading>Example &ndash; Constructing Iterators</Heading>

Iterators are a kind of objects that is implemented for several collections
in the &GAP; library and which might be interesting also in other cases,
see&nbsp;<Ref Sect="Iterators"/>.
A general setup for implementing new iterators is provided by
<Ref Func="IteratorByFunctions"/>.
<P/>
All one has to do is to write down the functions for
<Ref Func="NextIterator"/>,
<Ref Func="IsDoneIterator"/>,
and <Ref Func="ShallowCopy"/>, and to call
<Ref Func="IteratorByFunctions"/> with this record as argument.
For example, the following lines of code install an
<Ref Func="Iterator"/> method
for the case that the argument is the domain of rational integers.
<P/>
(Note that <Ref Func="IsIntegers"/> is a filter
that describes exactly the domain of rational integers.)
<P/>
<Log><![CDATA[
InstallMethod( Iterator,
    "for integers",
    [ IsIntegers ],
    Integers -> IteratorByFunctions( rec(
                    NextIterator:= function( iter ) ... end,
                    IsDoneIterator := ReturnFalse,
                    ShallowCopy := function( iter ) ... end ) ) );
]]></Log>
<P/>
The bodies of two of the functions have been omitted above;
here is the code that is actually used in &GAP;.
(The ordering coincides with that for the iterators for the domain of
rational integers that have been discussed in&nbsp;<Ref Sect="Component Objects"/>
and&nbsp;<Ref Sect="Positional Objects"/>.)
<P/>
<Example><![CDATA[
gap> iter:= Iterator( Integers );
<iterator of Integers at 0>
gap> Print( iter!.NextIterator, "\n" );
function ( iter )
    iter!.counter := iter!.counter + 1;
    if iter!.counter mod 2 = 0  then
        return iter!.counter / 2;
    else
        return (1 - iter!.counter) / 2;
    fi;
    return;
end
gap> Print( iter!.ShallowCopy, "\n" );   
function ( iter )
    return rec(
        counter := iter!.counter );
end
]]></Example>
<P/>
Note that the <C>ShallowCopy</C> component of the record must be a function
that does not return an iterator but a record that can be used as the
argument of <Ref Func="IteratorByFunctions"/>
in order to create the desired shallow copy.

</Section>


<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<Section Label="Arithmetic Issues in the Implementation of New Kinds of Lists">
<Heading>Arithmetic Issues in the Implementation of New Kinds of Lists</Heading>

When designing a new kind of list objects in &GAP;,
defining the arithmetic behaviour of these objects is an issue.
<P/>
There are situations where arithmetic operations of list objects
are unimportant in the sense that adding two such lists need not be
represented in a special way.
In such cases it might be useful either to support no arithmetics at all
for the new lists, or to enable the default arithmetic methods.
The former can be achieved by not setting the filters
<Ref Func="IsGeneralizedRowVector"/> and
<Ref Func="IsMultiplicativeGeneralizedRowVector"/>
in the types of the lists,
the latter can be achieved by setting the filter
<Ref Func="IsListDefault"/>.
(for details,
see&nbsp;<Ref Sect="Filters Controlling the Arithmetic Behaviour of Lists"/>).
An example for <Q>wrapped lists</Q> with default behaviour are vector space
bases;
they are lists with additional properties concerning the computation of
coefficients, but arithmetic properties are not important.
So it is no loss to enable the default methods for these lists.
<P/>
However, often the arithmetic behaviour of new list objects is important,
and one wants to keep these lists away from default methods for addition,
multiplication etc.
For example, the sum and the product of (compatible) block matrices shall
be represented as a block matrix, so the default methods for sum and
product of matrices shall not be applicable,
although the results will be equal to those of the default methods
in the sense that their entries at corresponding positions are equal.
<P/>
So one does not set the filter <Ref Func="IsListDefault"/>
in such cases,
and thus one can implement one's own methods for arithmetic operations.
<!-- % It should be stated explicitly what <Q>arithmetic operations</Q> means! -->
(Of course <Q>can</Q> means on the other hand that one <E>must</E> implement such
methods if one is interested in arithmetics of the new lists.)
<P/>
The specific binary arithmetic methods for the new lists will usually cover
the case that both arguments are of the new kind,
and perhaps also the interaction between a list of the new kind and certain
other kinds of lists may be handled if this appears to be useful.
<P/>
For the last situation, interaction between a new kind of lists and other
kinds of lists, &GAP; provides already a setup.
Namely, there are the categories
<Ref Func="IsGeneralizedRowVector"/> and
<Ref Func="IsMultiplicativeGeneralizedRowVector"/>,
which are concerned with the
additive and the multiplicative behaviour, respectively, of lists. 
For lists in these filters, the structure of the results of arithmetic
operations is prescribed (see&nbsp;<Ref Sect="Additive Arithmetic for Lists"/> and
<Ref Sect="Multiplicative Arithmetic for Lists"/>).
<P/>
For example,
if one implements block matrices in
<Ref Func="IsMultiplicativeGeneralizedRowVector"/>
then automatically the product of such a block matrix and a (plain) list
of such block matrices will be defined as the obvious list of matrix
products, and a default method for plain lists will handle this
multiplication.
(Note that this method will rely on a method for computing the product of
the block matrices, and of course no default method is available for that.)
Conversely, if the block matrices are not in
<Ref Func="IsMultiplicativeGeneralizedRowVector"/>
then the product of a block matrix
and a (plain) list of block matrices is not defined.
(There is no default method for it, and one can define the result and
provide a method for computing it.)
<P/>
Thus if one decides to set the filters
<Ref Func="IsGeneralizedRowVector"/> and
<Ref Func="IsMultiplicativeGeneralizedRowVector"/>
for the new lists,
on the one hand one loses freedom in defining arithmetic behaviour,
but on the other hand one gains several default methods for a more
or less natural behaviour.
<P/>
If a list in the filter <Ref Func="IsGeneralizedRowVector"/>
(<Ref Func="IsMultiplicativeGeneralizedRowVector"/>)
lies in <C>IsAttributeStoringRep</C>,
the values of additive (multiplicative) nesting depth is stored in
the list and need not be calculated for each arithmetic operation.
One can then store the value(s) already upon creation of the lists,
with the effect that the default arithmetic operations will access
elements of these lists only if this is unavoidable.
For example, the sum of two plain lists of <Q>wrapped matrices</Q> with
stored nesting depths are computed via the method for adding two such
wrapped lists, and without accessing any of their rows
(which might be expensive).
In this sense, the wrapped lists are treated as black boxes.

</Section>


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

An operation is defined for elements rather than for objects in the sense
that if the arguments are replaced by objects that are equal to the old
arguments w.r.t. the equivalence relation <Q><C>=</C></Q> then the result must be
equal to the old result w.r.t.&nbsp;<Q><C>=</C></Q>.
<P/>
But the implementation of many methods is representation dependent in the
sense that certain representation dependent subobjects are accessed.
<P/>
For example, a method that implements the addition of univariate
polynomials may access coefficients lists of its arguments
only if they are really stored,
while in the case of sparsely represented polynomials a different approach
is needed.
<P/>
In spite of this, for many operations one does not want to write an own
method for each possible representations of each argument,
for example because none of the methods could in fact take advantage
of the actually given representations of the objects.
Another reason could be that one wants to install first a representation
independent method, and then add specific methods as they are needed to
gain more efficiency, by really exploiting the fact that the arguments
have certain representations.
<P/>
For the purpose of admitting representation independent code,
one can define an <E>external representation</E> of objects in a given family,
install methods to compute this external representation for each
representation of the objects,
and then use this external representation of the objects whenever they
occur.
<P/>
We cannot provide conversion functions that allow us to first convert
any object in question to one particular <Q>standard representation</Q>,
and then access the data in the way defined for this representation,
simply because it may be impossible to choose such a <Q>standard
representation</Q> uniformly for all objects in the given family.
<P/>
So the aim of an external representation of an object <A>obj</A> is a
different one, namely to describe the data from which <A>obj</A> is composed.
In particular, the external representation of <A>obj</A> is <E>not</E> one possible
(<Q>standard</Q>) representation of <A>obj</A>,
in fact the external representation of <A>obj</A> is in general different
from <A>obj</A> w.r.t.&nbsp;<Q><C>=</C></Q>,
first  of all because the external representation of <A>obj</A> does in general
not lie in the same family as <A>obj</A>.
<P/>
For example the external representation of a rational function is a list
of length two or three, the first entry being the zero coefficient,
the second being a list describing the coefficients and monomials of the
numerator, and the third, if bound, being a list describing the coefficients
and monomials of the denominator.
In particular, the external representation of a polynomial is a list
and not a polynomial.
<P/>
The other way round, the external representation of <A>obj</A> encodes <A>obj</A>
in such a way that from this data and the family of <A>obj</A>,
one can create an object that is equal to <A>obj</A>.
Usually the external representation of an object is a list or a record.
<P/>
Although the external representation of <A>obj</A> is by definition independent
of the actually available representations for <A>obj</A>,
it is usual that a representation of <A>obj</A> exists for which the
computation of the external representation is obtained by just
<Q>unpacking</Q> <A>obj</A>,
in the sense that the desired data is stored in a component or a position
of <A>obj</A>, if <A>obj</A> is a component object (see&nbsp;<Ref Sect="Component Objects"/>)
or a positional object (see&nbsp;<Ref Sect="Positional Objects"/>).
<P/>
To implement an external representation means to install methods for the
following two operations.

<ManSection>
<Oper Name="ExtRepOfObj" Arg='obj'/>
<Oper Name="ObjByExtRep" Arg='fam, data'/>

<Description>
<Ref Func="ExtRepOfObj"/> returns the external representation of its argument,
and <Ref Func="ObjByExtRep"/> returns an object in the family <A>fam</A>
that has external representation <A>data</A>.
<P/>
Of course,
<C>ObjByExtRep( FamilyObj( <A>obj</A> ), ExtRepOfObj( <A>obj</A> ) )</C>
must be equal to <A>obj</A> w.r.t. the operation
<Ref Func="\="/>.
But it is <E>not</E> required that equal objects have equal external
representations.
<P/>
Note that if one defines a new representation of objects for which an
external representation does already exist
then one <E>must</E> install a method to compute this external representation
for the objects in the new representation.
</Description>
</ManSection>

</Section>


<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<Section Label="Mutability and Copying">
<Heading>Mutability and Copying</Heading>

Any &GAP; object is either mutable or immutable. This can be tested
with the function <Ref Func="IsMutable"/>.
The intended meaning of (im)mutability is a mathematical one:
an immutable object should never change in
such a way that it represents a different Element. Objects <E>may</E>
change in other ways, for instance to store more information, or
represent an element in a different way.
<P/>
Immutability is enforced in different ways for built-in objects (like
records, or lists) and for external objects (made using
<Ref Func="Objectify"/>).
<P/>
For built-in objects which are immutable, the kernel will prevent
you from changing them. Thus
<P/>
<Example><![CDATA[
gap> l := [1,2,4];
[ 1, 2, 4 ]
gap> MakeImmutable(l);
[ 1, 2, 4 ]
gap> l[3] := 5;
Error, Lists Assignment: <list> must be a mutable list
]]></Example>
<P/>
For external objects, the situation is different. An external object which
claims to be immutable (i.e. its type does not contain
<Ref Func="IsMutable"/>)
should not admit any methods which change the element it represents.
The kernel does <E>not</E> prevent the use of <C>!.</C> and <C>![</C>
to change the underlying data structure.
This is used for instance by the code that stores attribute values for reuse.
In general, these <C>!</C> operations should only be used in methods
which depend on the representation of the object.
Furthermore, we would <E>not</E>
recommend users to install methods which depend on the representations of
objects created by the library or by &GAP; packages, as there is certainly no
guarantee of the representations being the same in future versions of &GAP;.
<P/>
Here we see an immutable object (the group <M>S_4</M>), in which we improperly
install a new component.
<P/>
<Example><![CDATA[
gap> g := SymmetricGroup(IsPermGroup,4);
Sym( [ 1 .. 4 ] )
gap> IsMutable(g);
false
gap> NamesOfComponents(g);
[ "Size", "NrMovedPoints", "MovedPoints", 
  "GeneratorsOfMagmaWithInverses" ]
gap> g!.silly := "rubbish";
"rubbish"
gap> NamesOfComponents(g);
[ "Size", "NrMovedPoints", "MovedPoints", 
  "GeneratorsOfMagmaWithInverses", "silly" ]
gap> g!.silly;
"rubbish"
]]></Example>
<P/>
On the other hand, if we form an immutable externally represented list, we
find that &GAP; will not let us change the object.
<P/>
<Example><![CDATA[
gap> e := Enumerator(g);
<enumerator of perm group>
gap> IsMutable(e);
false
gap> IsList(e);
true
gap> e[3];
(1,2,4)
gap> e[3] := false;
Error, The list you are trying to assign to is immutable
]]></Example>
<P/>
When we consider copying objects, another filter
<Ref Func="IsCopyable"/>, enters the game and we find that
<Ref Func="ShallowCopy"/> and
<Ref Func="StructuralCopy"/> behave quite
differently. Objects can be divided for this purpose into three:
mutable objects, immutable but copyable objects, and non-copyable
objects (called constants).
<P/>
A mutable or copyable object should have a method for the operation
<Ref Func="ShallowCopy"/>,
which should make a new mutable object, sharing its top-level
subobjects with the original. The exact definition of top-level subobject may
be defined by the implementor for new kinds of object.
<P/>
<Ref Func="ShallowCopy"/> applied to a constant
simply returns the constant.
<P/>
<Ref Func="StructuralCopy"/> is expected to be much less used
than <Ref Func="ShallowCopy"/>.
Applied to a mutable object, it returns a new mutable
object which shares no mutable sub-objects with the input. Applied to
an immutable object (even a copyable one), it just returns the
object. It is not an operation (indeed, it's a rather special kernel
function).
<P/>
<Example><![CDATA[
gap> e1 := StructuralCopy(e);
<enumerator of perm group>
gap> IsMutable(e1);
false
gap> e2 := ShallowCopy(e);
[ (), (1,4), (1,2,4), (1,3,4), (2,4), (1,4,2), (1,2), (1,3,4,2), 
  (2,3,4), (1,4,2,3), (1,2,3), (1,3)(2,4), (3,4), (1,4,3), (1,2,4,3), 
  (1,3), (2,4,3), (1,4,3,2), (1,2)(3,4), (1,3,2), (2,3), (1,4)(2,3), 
  (1,2,3,4), (1,3,2,4) ]
gap> 
]]></Example>
<P/>
There are two other related functions:
<Ref Func="Immutable"/>, which makes a new
immutable object which shares no mutable subobjects with its input and
<Ref Func="MakeImmutable"/> which changes an object and its
mutable subobjects <E>in place</E> to be immutable.
It should only be used on <Q>new</Q> objects that
you have just created, and which cannot share mutable subobjects with
anything else.
<P/>
Both <Ref Func="Immutable"/> and
<Ref Func="MakeImmutable"/> work on external objects by just
resetting the <Ref Func="IsMutable"/> filter
in the object's type. This should make
ineligible any methods that might change the object. As a consequence,
you must allow for the possibility of immutable versions of any
objects you create.
<P/>
So, if you are implementing your own external objects. The rules amount to the
following:
<P/>
<Enum>
  <Item>
    You decide if your objects should be mutable or copyable or constants, by
    fixing whether their type includes <Ref Func="IsMutable"/>
    or <Ref Func="IsCopyable"/>.
  </Item>
  <Item>
    You install methods for your objects respecting that decision:
    <List>
      <Mark>for constants:</Mark>
      <Item>
        no methods change the underlying elements;
      </Item>
      <Mark>for copyables:</Mark>
      <Item>
        you provide a method for <Ref Func="ShallowCopy"/>;
      </Item>
      <Mark>for mutables:</Mark>
      <Item>
        you may have methods that change the underlying elements
        and these should explicitly require
        <Ref Func="IsMutable"/>.
      </Item>
    </List>
  </Item>
</Enum>

</Section>


<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<Section Label="Global Variables in the Library">
<Heading>Global Variables in the Library</Heading>

Global variables in the &GAP; library are usually read-only in order to
avoid their being overwritten accidentally.

See also Section <Ref Sect="More About Global Variables"/>.

<#Include Label="DeclareCategory">
<#Include Label="DeclareRepresentation">
<#Include Label="DeclareAttribute">
<#Include Label="DeclareProperty">
<#Include Label="DeclareFilter">
<#Include Label="DeclareOperation">
<#Include Label="DeclareGlobalFunction">
<#Include Label="DeclareGlobalVariable">
<#Include Label="InstallValue">
<#Include Label="DeclareSynonym">
<#Include Label="FlushCaches">

</Section>


<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<Section Label="Declaration and Implementation Part">
<Heading>Declaration and Implementation Part</Heading>

Each package of &GAP; code consists of two parts,
the <E>declaration part</E> that defines the new categories and operations for
the objects the package deals with,
and the <E>implementation part</E> where the corresponding methods are
installed.
The declaration part should be representation independent,
representation dependent information should be dealt with in the
implementation part.
<P/>
&GAP; functions that are not operations and that are intended to be
called by users should be notified to &GAP; in the declaration part via
<Ref Func="DeclareGlobalFunction"/>.
Values for these functions can be installed in the implementation part
via <Ref Func="InstallGlobalFunction"/>.
<P/>
Calls to the following functions belong to the declaration part.
<P/>
<Ref Func="DeclareAttribute"/>,
<P/>
<Ref Func="DeclareCategory"/>,
<P/>
<Ref Func="DeclareFilter"/>,
<P/>
<Ref Func="DeclareOperation"/>,
<P/>
<Ref Func="DeclareGlobalFunction"/>,
<P/>
<Ref Func="DeclareSynonym"/>,
<P/>
<Ref Func="DeclareSynonymAttr"/>,
<P/>
<Ref Func="DeclareProperty"/>,
<P/>
<Ref Func="InstallTrueMethod"/>.
<P/>
Calls to the following functions belong to the implementation part.
<P/>
<Ref Func="DeclareRepresentation"/>,
<P/>
<Ref Func="InstallGlobalFunction"/>,
<P/>
<Ref Func="InstallMethod"/>,
<P/>
<Ref Func="InstallImmediateMethod"/>,
<P/>
<Ref Func="InstallOtherMethod"/>,
<P/>
<Ref Func="NewFamily"/>,
<P/>
<Ref Func="NewType"/>,
<P/>
<Ref Func="Objectify"/>.
<P/>
<Index Key="DeclareRepresentation" Subkey="belongs to implementation part">
<C>DeclareRepresentation</C></Index>
Whenever both a <C>New</C><A>Something</A> and a
<C>Declare</C><A>Something</A> variant of a function exist
(see&nbsp;<Ref Sect="Global Variables in the Library"/>),
the use of <C>Declare</C><A>Something</A> is recommended
because this protects the variables in question from being overwritten.
Note that there are <E>no</E> functions <C>DeclareFamily</C> and
<C>DeclareType</C> since families and types are created dynamically,
hence usually no global variables are associated to them.
Further note that <Ref Func="DeclareRepresentation"/> is regarded as
belonging to the implementation part,
because usually representations of objects are accessed only in very
few places, and all code that involves a particular representation
is contained in one file;
additionally, representations of objects are often not interesting
for the user, so there is no need to provide a user interface
or documentation about representations.
<P/>
It should be emphasized that <Q>declaration</Q> means only an explicit
notification of mathematical or technical terms or of concepts to &GAP;.
For example, declaring a category or property with name <C>IsInteresting</C>
does of course not tell &GAP; what this shall mean,
and it is necessary to implement possibilities to create objects that
know already that they lie in <C>IsInteresting</C> in the case that it is a
category, or to install implications or methods in order to
compute for a given object whether <C>IsInteresting</C> is <K>true</K> or <K>false</K>
for it in the case that <C>IsInteresting</C> is a property.

</Section>
</Chapter>


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