Why are many attribute mutable / can the group in a recognition node change?

[fingolfin]

Why are all these attributes mutable (i.e. can be changed later on):

gap/base/recognition.gd:111:DeclareAttribute( "Grp", IsRecogNode, "mutable" );
gap/base/recognition.gd:125:DeclareAttribute( "Homom", IsRecogNode, "mutable" );
gap/base/recognition.gd:150:DeclareAttribute( "NiceGens", IsRecogNode, "mutable" );
gap/base/recognition.gd:166:DeclareAttribute( "ImageRecogNode", IsRecogNode, "mutable" );
gap/base/recognition.gd:186:DeclareAttribute( "KernelRecogNode", IsRecogNode, "mutable" );
gap/base/recognition.gd:200:DeclareAttribute( "ParentRecogNode", IsRecogNode, "mutable" );
gap/base/recognition.gd:212:DeclareAttribute( "StdPresentation", IsRecogNode, "mutable" );    # TODO: implement
gap/base/recognition.gd:231:DeclareAttribute( "pregensfac", IsRecogNode, "mutable" );
gap/base/recognition.gd:256:DeclareAttribute( "calcnicegens", IsRecogNode, "mutable" );
gap/base/recognition.gd:270:DeclareAttribute( "slptonice", IsRecogNode, "mutable" );
gap/base/recognition.gd:284:DeclareAttribute( "fhmethsel", IsRecogNode, "mutable" );      # TODO: rename?
gap/base/recognition.gd:304:DeclareAttribute( "methodsforimage", IsRecogNode, "mutable" ); # rename to MethodsDBForFactor
gap/base/recognition.gd:328:DeclareAttribute( "slpforelement", IsRecogNode, "mutable" );
gap/base/recognition.gd:330:DeclareAttribute( "gensN", IsRecogNode, "mutable" );      # TODO: rename?
gap/base/recognition.gd:333:DeclareAttribute( "findgensNmeth", IsRecogNode, "mutable" );
gap/base/recognition.gd:335:DeclareAttribute( "gensNslp", IsRecogNode, "mutable" );
gap/base/recognition.gd:337:DeclareAttribute( "immediateverification", IsRecogNode, "mutable" );
gap/base/recognition.gd:339:DeclareAttribute( "InitialDataForKernelRecogNode", IsRecogNode, "mutable" );
gap/base/recognition.gd:342:DeclareAttribute( "InitialDataForImageRecogNode", IsRecogNode, "mutable" );
gap/base/recognition.gd:345:DeclareAttribute( "isone", IsRecogNode, "mutable" );
gap/base/recognition.gd:347:DeclareAttribute( "isequal", IsRecogNode, "mutable" );
gap/base/recognition.gd:349:DeclareAttribute( "OrderFunc", IsRecogNode, "mutable" );
gap/base/recognition.gd:351:DeclareAttribute( "docommute", IsRecogNode, "mutable" );

Specifically: can the group (Grp) in a recognition node change later on?
I really hope not, else all kind of things can break.

About the only reason I can think of why a node might need to be changed is that kernels could get additional generators later on. But in that case, shouldn't we create a fresh node, which starts from scratch (OK a few things could probably be transferred, but that should be selective).

But I really hope now...

I'd like to change many (most? all?) of these to be immutable, buuuuut: in GAP, if you try to change an already set attribute, it just ignores your request. That's unfortunate: I'd much prefer if it gave an error, so that I can catch cases that actually modify existing code. Urgh.

[ThomasBreuer]

The last paragraph sounded strange to me, but now I catch the point:
Apparently the setters of mutable attributes overwrite already stored values. (And this has been the case for a long time.)

But why is this the case?

According to the documentation in the section "NewAttribute", an attribute that is declared as mutable stores a mutable value, and the section "Setter and Tester for Attributes" explains that an attribute value gets set by calling the setter function of the attribute. However, there is no statement that setters of immutable and mutable attributes behave differently in the sense that calling the setter of a mutable attribute again will overwrite the already stored value. The manual explains why mutable attribute values are useful (for storing lists or records that may get filled later on), and from this viewpoint it makes no sense that the setters of mutable attributes overwrite stored values.

[fingolfin]

I am fine with setters of mutable attributes overwriting the content; that is kind of the point of having mutable attributes in the first place!

But what I am unhappy about here is that immutable attributes silently ignore attempts to change an already set value, instead of raising an error.

The reason is this: I think that currently, nothing changes the value of these mutable attributes after they have been set initially. But I cannot be sure. Now, if my assumption is right, it is safe to change these mutable attributes to immutable attributes.

But if I am wrong, then this will causes buggy behaviour that is hard to track down, as the code which previously managed to change an attribute now silently fails.

For now the only way out to me seems to be to simply not use GAP's regular attribute system at all, and instead use custom setter/getter which raise an error on any attempts to modify a previously set attribute.

This is a real shame, though. Hmmm, perhaps we could also mitigate this by providing custom setter methods which have the required checks to raise errors if an attribute value is being changed.

[ThomasBreuer]

I am fine with setters of mutable attributes overwriting the content; that is kind of the point of having mutable attributes in the first place!

I disagree.
My understanding was always that mutable attributes have mutable values in the sense that the stored value can be changed, but not that it can be replaced.
From my point of view, the idea to replace stored attribute values is dangerous,
and the fact that simply calling the setter results in such a replacement is frightening.
It would be better if setter calls were always ignored if a value is already stored, but it is too late for such a design change.