`RUN_IN_GGMBI` handling

[ThomasBreuer]

RUN_IN_GGMBI is an undocumented global variable that is used for avoiding infinite recursions.

Such flags can cause problems in interactive sessions when one enters a break loop, leaves it with quit, and the flag keeps its non-default value.
(An example where this happened for another global flag is described in #6412. Here the solution was to remove that flag -- problem solved.)

One way to improve the behaviour of GAP would be to explicitly reset RUN_IN_GGMBI in OnQuit, that is, when one returns from an error to the GAP prompt.
Alternatively, would it make sense to turn RUN_IN_GGMBI into a global option? In this case, OnQuit would automatically reset the value when the whole options stack gets reset.

(Challenge: Which other global flags do we have, which would need to be reset in OnQuit?)

[fingolfin]

Using a "global option" for this sounds good to me.

One caveat: RUN_IN_GGMBI is also set in the matgrp package by @hulpke ... So we'd need to come up with a migration solution.

One option is that we keep RUN_IN_GGMBI around and test it, but never set it, in the library (other than to an initial value).

And then matgrp can simply keep setting it and also setting the global option (old GAP versions will ignore it)

[hulpke]

Option would be fine.

I would be happy to make a version of matgrp that (e.g.) tests for `IsBound(RUN_IN_GGMBI) and uses the option if not.

[hulpke]

@ThomasBreuer @fingolfin
For updating the matgrp package, I need to provide old and new variant until the new GAP is released. How should I detect (without horrible hacks such as reading in source code...) that the option-based version is now preferred? I cannot check on RUN_IN_GGMBI still being bound.

[ThomasBreuer]

The change is not yet in GAP 4.16.0.
If we want to provide it in GAP 4.16.1, then we should backport #6442 to GAP 4.16.
Once this has happened, the GAP version can be used for deciding whether the new option is supported.

[fingolfin]

I would advise against a version based test. Instead, I suggest we change the default value of RUN_IN_GGMBI to fail here in GAP (it won't make a difference, as we explicitly check RUN_IN_GGMBI = true.

Then, in matgrp you can check if RUN_IN_GGMBI = fail (then don't try to set RUN_IN_GGMBI to true or false). This will work because GAP itself never touches RUN_IN_GGMBI (well... in one .tst file... but that one can just also reset it to fail). And if matgrp detects the situation, it will also not touch it, and all will be good.

(If you folks feel this is too hacky, we could also add an explicit variable RUN_IN_GGMBI_DEPRECATED := true; or so. In any case: property/behavior based checks are preferable over version based checks, which e.g. fails in GAP development versions.)

And of course it is safe to just always pass the global option Run_In_GGMBI (old GAP versions will just ignore it).

[hulpke]

Thank you, @fingolfin . The first version is what I would have implemented myself. but I could easily live with the second one.

Indeed one could also just do both simultaneously. The question is just whether we want to keep the variable RUN_IN_GGMBI long term so that assignment does not cause syntax errors.

[ThomasBreuer]

version based checks, which e.g. fails in GAP development versions

Why?
In GAP development versions, GAPInfo.Version ends with dev, and CompareVersionNumbers considers such a version number as infinite.