Make ArithmeticElementCreator understand re-read mode

[fingolfin]

In GAP one can use Reread (and its variants) instead of Read (and its variants) while developing code; this suppresses errors caused by re-defining global read-only variables.

But this didn't work when using ArithmeticElementCreator because that had its own check for detecting and rejecting such redefinitions.

This patch teaches it to honor the REREADING global for a smoother developer experience.

Based on questions by @TWiedemann

[ThomasBreuer]

The proposed change addresses the situation where a file gets read with Reread that contains a call to ArithmeticElementCreator.

With this change the following happens.

• Read the file for the first time. Let us assume the return value of ArithmeticElementCreator is assigned to the variable aec afterwards.
• Create some arithmetic objects: a:= aec( ... ); b:= aec( ... ); ....
• Reread the file. Now aec is a new object.
• Create more arithmetic objects: c:= aec( ... ); ....
• Now a + b works, but a + c does not work because a and c have been created by different creator objects.

In this sense, isn't this change asking for trouble?

Of course one can argue that the same happens if a file contains the creation of a free group, and rereading this file will create a new group whose elements are not compatible with elements of the original group.
However, I think the difference is that here one can see that the underlying objects are different, whereas the return value of ArithmeticElementCreator looks like an innocent function, and rereading such code is regarded as safe.

[fingolfin]

While all your points are valid, I still think this change is beneficial: in the end, Reread is a very sharp tool; even without ArithmeticElementCreator involved it can cause severe trouble, and the problems you list can also appear there.

In my eyes it is a low-level tool for developers who (think they) know what they are doing. I see no advantage in defeating it in this scenario for the sake of protecting developers from shooting themselves in their foot -- in my mind if we followed that line of reasoning then we should abolish Reread completely. (To be clear, I don't want that ;-) )

[fingolfin]

@ChrisJefferson any thoughts on this?

[ChrisJefferson]

I agre I'm happy with this. I'd also be happy to ban Reread, but if we are going to keep supporting it, this make is function in another case. There are lots of ways Reread can get you in an inconsistent state.