Change GroupWithGenerators to accept collections again

[fingolfin]

In GAP <= 4.9, this worked:

gap> GroupByGenerators( Group( (1,2) ) );
Group([ (), (1,2) ])

In GAP 4.10, this was broken and instead lead to a "method not found" error.
While strictly speaking this was never documented behavior, we restore it
to avoid regressions in code that relied on this undocumented behavior.

Resolves #2703

This is a less intrusive (and thus hopefully less controversial) alternative to PR #3091. Closes #3091

[ThomasBreuer]

These changes fix the behavior, fine.
My only suggestion is to omit the AsList calls
inside the ObjectifyWithAttributes calls,
since AsList has been applied already.

[olexandr-konovalov]

Frst off, this modifies both GroupByGenerators and GroupWithGenerators but the commit message mentions only the former one.

Furthermore, I am not convinced that calling AsList is a good idea. Imagine if someone asks, for example:

GroupByGenerators(SymmetricGroup(20))

Are we seriously expecting AsList(SymmetricGroup(20)) to complete? ;-) By the way, this applies to both PRs, as the same call to AsList is present in #3091.

The other idea suggested elsewhere was to check if the argument is a domain which knows a list of its generators, and in this case call GroupByGenerators on that list. At least that would allow to avoid expanding domain to a list of its elements. But again, to be done consistently, this should be done for all *ByGenerators methods... and perhaps also for *WithGenerators? Hmm... that would also seem controversial - but if done, then the use like that must be documented. However, I'd prefer to not do do it at all. I do think that a proper solution would be just to make a new CTblLib release. That's the only known manifestation of this problem I have discovered so far.

[ChrisJefferson]

I don't like the idea that is something doesn't break any library code, that's fine. There are many thousands of GAP users out in the world, all with their own code. If (as in this case) it is reasonable for us not to break existing code, which has worked for many years, then I think we should try to do so -- particularly when the error message is hard to read.

There are many places in GAP where you can put objects which can be enumerated instead of an explicit list, and in any of those places SymmetricGroup(20) would be a bad idea.

[codecov]

Codecov Report

Merging #3095 into master will decrease coverage by 0.22%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #3095      +/-   ##
==========================================
- Coverage   83.56%   83.33%   -0.23%     
==========================================
  Files         686      686              
  Lines      336733   336735       +2     
==========================================
- Hits       281380   280610     -770     
- Misses      55353    56125     +772

Impacted Files	Coverage Δ
lib/grp.gi	88.96% <100%> (ø)	⬆️
src/compiler.c	66.34% <0%> (-22.49%)	⬇️
src/vars.c	81.28% <0%> (-12.19%)	⬇️
src/stats.c	85.71% <0%> (-9.6%)	⬇️
src/error.c	75.47% <0%> (-9.58%)	⬇️
src/exprs.c	92.9% <0%> (-4.44%)	⬇️
src/intrprtr.c	94.8% <0%> (-4.09%)	⬇️
src/funcs.c	95.39% <0%> (-2.46%)	⬇️
src/opers.c	92.96% <0%> (-2.21%)	⬇️
src/sysmem.c	55.88% <0%> (-1.77%)	⬇️
... and 9 more

[olexandr-konovalov]

@ChrisJefferson there is still an alternative:

The other idea suggested elsewhere was to check if the argument is a domain which knows a list of its generators, and in this case call GroupByGenerators on that list.

I would be happy with one of the following:

• document the alternative behaviour as above, or

• make a better error message when it's called with a domain, or

• accept this PR with the following modification: if it called on a domain, then it does everything like it does now (i.e. calls AsList) but prints a warning:

  #I Calling GroupByGenerators on a domain is very inefficient, use the list of generators instead.

Anyone in favour?

[fingolfin]

@ThomasBreuer ah, thanks for pointing out the extra AsList calls; they are now removed

@alex-konovalov this only modifies two methods for GroupWithGenerators, hence I only mention that in the commit message (well, now at least, I had GroupByGenerators in there and in the title of this PR before by accident). Of course this then also affects any code calling or delegating to GroupWithGenerators, such as GroupByGenerators.

Of course GroupByGenerators(SymmetricGroup(20)) is not sensible, but so what? This just restores behaviour that was present in GAP 4.9, while not affecting anything else. In particular, any "sane" code which only passes in regular list of generators sees no change in behavior.

Put another way: any code that currently is "correct" and "adheres to the documentation" will work unchanged. All this PR does is to restore a behavior of GAP that was present for decades (I just checked, GAP 4.4 supports it). I see zero harm in it. Note that I am not suggesting to document this behavior, either, but I don't see how we benefit from gratuitously breaking code that was working before?

[olexandr-konovalov]

@fingolfin This will not fix #2703 because that one goes into the break loop because of GroupByGenerators.

[fingolfin]

@alex-konovalov while I wouldn't mind that warning, IMHO it should be added in a separate PR. This PR is purely about restoring behaviour that was present in GAP for the past 20+ years. To this end, I strove for a minimal set of changes. Any further changes and optimizations, documentation etc. are IMHO beyond the scope of this.

And as I said before: GroupByGenerators delegates to GroupWithGenerators. I even added a .tst file which verifies this.

[olexandr-konovalov]

Oh yes, thanks for pointing out, of course, one delegates to another.

The new commit message looks correct, so I will approve this now, and agree that we keep this undocumented. I will make a PR with a warning if this PR will pass the testing round.

[fingolfin]

Backported via ac82a50