in general, do not use a known `Name` value in `PrintObj`

[ThomasBreuer]

This addresses #5699.

For more than 25 years, there is a PrintObj method with high rank that just prints a known Name value of the object in question. According to the documentation of Name, a known Name value should be used only by View and ViewObj; the function Print is recommended to show GAP input to reconstruct the object in question if this makes sense.

When we remove the PrintObj method in question, the tests from testinstall and teststandard show differences essentially in two situations:

• Certain global variables such as Rationals are currently expected to be printed via this name. The solution proposed here is to provide a PrintObj method with high rank that uses a known name under the condition that a global variable with this name exists.
• Some tests for groups returned by SimpleGroupsIterator call Print in order to show the names of these groups. Here we can call View instead of Print.

(Let us see the results of the other tests, perhaps there are more differences.)

[ThomasBreuer]

No, apparently the CI tests do not complain about the proposed change. So is this a reasonable solution to Leonard's problem?

[Stefan-Kohl]

Would this really be a good idea? -- I mean, for example assume you name an object "X". Then, as I understand, with your proposal this would still be "Print"ed as "X", as there is a global variable named "X". (Or did I misread something?)

[ThomasBreuer]

@Stefan-Kohl

Would this really be a good idea? -- I mean, for example assume you name an object "X". Then, as I understand, with your proposal this would still be "Print"ed as "X", as there is a global variable named "X". (Or did I misread something?)

Well, this has been the behaviour since more than 25 years, and nobody has reported a problem with it. Yes, one can set misleading names. If a user does this then it is his/her fault, and View will continue showing these names. (I think that function names such as X cause less confusion than names of objects such as Rationals.)

I think that Name should not be set by library functions, but this is another question to be answered.

[fingolfin]

Causes failures in the test suites of 18 9 GAP packages, see https://github.com/gap-system/PackageDistro/actions/runs/11401453048

[ThomasBreuer]

I see three different reasons for the failures in package tests:

1. The global objects SqrtField (packages corelg, nock) and QuantumField (package quagroup) have a Name value, which is no longer used in View output for algebras over these objects etc.; here we could add individual PrintObj methods as for Rationals etc.
2. Individual objects created by package code get Name values, similar to the output of PrimitiveGroup, and the ViewObj method for something involving these objects calls PrintObj for them.
3. There are Info calls in the tests of the crisp package, where individual objects with Name value occur as arguments.

I have no easy solution for the cases 2. and 3. At least some of the ViewObj methods belong to the package in question, but in fact many ViewObj methods in the GAP library call Print for subobjects. It would be more logical to call View in these situations, but I am afraid we do not really want to change all this.

[ThomasBreuer]

For the moment, I give up: A clean solution would require changes in a lot of ViewObj methods in the GAP library (and in packages) which call Print for certain subobjects. I think the benefits are too small, compared to the efforts.