An object in GAP is said to be immutable if its mathematical value (as defined by = ) does not change under any operation. More explicitly, suppose a is immutable and O is some operation on a, then if a = b evaluates to true before executing O(a), a = b also evaluates to true afterwards. An immutable object may change, for example to store new information, or to adopt a more efficient representation, but this does not affect its behaviour under = .
There are two points here to note. Firstly, operation above
refers to the functions and methods which can legitimately be
applied to the object, and not the !. operation whereby
virtually any aspect of any GAP level object may be changed.
The second point which follows from this, is that when
implementing new types of objects, it is the programmer's
responsibility to ensure that the functions and methods they write
never change immutable objects mathematically.
In fact, most objects with which one deals in GAP are immutable.
For instance, the permutation (1,2) will never become a
different permutation or a non-permutation (although a variable which
previously had (1,2) stored in it may subsequently have some other
value).
For many purposes, however, mutable objects are useful. These objects may be changed to represent different mathematical objects during their life. For example, mutable lists can be changed by assigning values to positions or by unbinding values at certain positions. Similarly, one can assign values to components of a mutable record, or unbind them.
IsMutable( obj ) C
tests whether obj is mutable.
If an object is mutable, then it is also
copyable, and there should be a ShallowCopy method supplied for it.
Note that no other filter must imply IsMutable,
since otherwise Immutable would be able to create paradoxical objects.
In many situations, however, one wants to ensure that objects are immutable. For example, take the identity of a matrix group. Since this matrix may be referred to as the identity of the group in several places, it would be fatal to modify its entries, or add or unbind rows. We can obtain an immutable copy of an object with:
Immutable( obj ) O
returns an immutable structural copy of obj in which the subobjects
are immutable copies of the subobjects of obj.
If obj is immutable then Immutable returns obj itself.
GAP will complain with an error if one tries to change an immutable object.
MakeImmutable( obj ) F
One can turn the (mutable or immutable) object obj into an immutable
one with MakeImmutable; note that this also makes all subobjects of
obj immutable, so one should call MakeImmutable only if obj and
its mutable subobjects are newly created. If one is not sure about
this, Immutable should be used.
Note that it is not possible to turn an immutable object into a mutable one; only mutable copies can be made (see Duplication of Objects).
Using Immutable, it is possible to store an immutable identity
matrix or an immutable list of generators, and to pass around
references to this immutable object safely. Only when a mutable
copy is really needed does the actual object have to be duplicated.
Compared to the situation without immutable objects, much unnecessary
copying is avoided this way. Another advantage of immutability is
that lists of immutable objects may remember whether they are sorted
(see Sorted Lists and Sets), which is not possible for lists of
mutable objects.
Objects for which only an immutable form exists in GAP are called
constants. Examples of constants are integers, permutations, and
domains. Called with a constant as argument, Immutable and
ShallowCopy return this argument.
IsCopyable( obj ) C
If a mutable form of an object obj can be made in GAP,
the object is called copyable. Examples of copyable objects are of
course lists and records. A new mutable version of the object can
always be obtained by the operation ShallowCopy (see Duplication of Objects).
Note that, since a matrix is a list of lists, the behaviour of
ShallowCopy for a matrix must respect that for a list, so that given
an immutable matrix mat, ShallowCopy returns a mutable matrix
whose rows are identical to the rows of mat. In particular the
rows are still immutable. To get a matrix whose rows are mutable, one
can use List( mat, ShallowCopy ).
Since the operation Immutable must work for any object in GAP, it
follows that an immutable form of every object must be possible, even
if it is not sensible, and user-defined objects must allow for the
possibility of becoming immutable without notice.
Another interesting example of mutable (and thus copyable) objects is
provided by iterators, see Iterators. (Of course an immutable
form of an iterator is not very useful, but clearly Immutable will
yield such an object.) Every call of NextIterator changes a mutable
iterator until it is exhausted, and this is the only way to change an
iterator. ShallowCopy for an iterator iter is defined so as to return a
mutable iterator that has no mutable data in common with iter, and
that behaves equally to iter w.r.t. IsDoneIterator and (if iter
is mutable) NextIterator. Note that the meaning of the ``shallow
copy'' of an iterator that is returned by ShallowCopy is not as
obvious as for lists and records, and must be explicitly defined.
Many operations return immutable results, among those mainly
attributes (see Attributes); examples of attributes are 'Size',
Zero, AdditiveInverse, One, and Inverse. Arithmetic
operations, such as the binary infix operations +, -, *, /,
^, mod, the unary -, and operations such as Comm and
LeftQuotient, return mutable results, except if the operation is
binary and both arguments are immutable. So the product of two
matrices or of a vector and a matrix is immutable if and only if the
two matrices or both the vector and the matrix are immutable (see
also Arithmetic for Lists). It should be noted that 0 * obj is
equivalent to ZeroOp( obj ), -obj is equivalent to
AdditiveInverseOp( obj ), obj^0 is equivalent to OneOp( obj
), and obj^-1 is equivalent to InverseOp( obj ). The
operations ZeroOp, AdditiveInverseOp, OneOp, and InverseOp
return mutable results whenever a mutable version of the result
exists, contrary to the attributes Zero, AdditiveInverse, One,
and Inverse.
If one introduces new arithmetic objects then one need not install
methods for the attributes One, Zero, etc.
The methods for the associated operations OneOp and ZeroOp
will be called, and then the results made immutable.
All methods installed for the arithmetic operations must obey the rule about the mutability of the result. This means that one may try to avoid the perhaps expensive creation of a new object if both operands are immutable, and of course no problems of this kind arise at all in the usual case that the objects in question are not copyable.
In a few, relatively low-level algorithms, one wishes to treat a
matrix partly as a data structure, and manipulate and change its
entries. For this, the matrix needs to be mutable, and the rule that
attribute values are immutable is an obstacle. For these situations,
a number of additional operations are provided, for example
MutableTransposedMat constructs a mutable matrix (contrary to the
attribute TransposedMat), while TriangulizeMat modifies a mutable
matrix (in place) into upper triangular form.
Note that being immutable does not forbid an object to store knowledge. For example, if it is found out that an immutable list is strictly sorted then the list may store this information. More precisely, an immutable object may change in any way, provided that it continues to represent the same mathematical object.
[Top] [Previous] [Up] [Next] [Index]
GAP 4 manual