Add kernel helper IS_FILTER, other tweaks

[fingolfin]

In particular, before this PR, we get this:

gap> Center and IsAssociative;
<Filter "(Centre and IsAssociative)">
gap> FirstOp and IsAssociative;
Error, <flags1> must be a flags list (not a boolean or fail)

Note that Center is an attribute, not a filter.

With this PR:

gap> Center and IsAssociative;
Error, <expr> must be 'true' or 'false' or a filter (not a function)
gap> FirstOp and IsAssociative;
Error, <expr> must be 'true' or 'false' or a filter (not a function)

In addition, argument validation for and differed slightly between interpreter and executor, which this PR also fixes.

I am on the fence whether this should be considered relevant for the release notes. On the one hand, probably nobody ever noticed these quirks. On the other, this is a change in what kind of inputs GAP accepts...

[fingolfin]

So, this abuses enabled as a bit array. Since it now stores two bits (not just one), perhaps we should rename it. But I couldn't think of a good name -- my only idea, flags, already is used by another field in struct OperBag...

[markuspf]

other ideas include properties (could be misunderstood), bits or bitlist (not very descriptive), options (not really options); they're all bad in some way.

With bits one could work with some macros, maybe.

[fingolfin]

Actually I screwed up SET_ENABLED_ATTR in here. I'll fix that now and also rename enabled.

[codecov]

Codecov Report

Merging #2732 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #2732      +/-   ##
==========================================
+ Coverage   75.78%   75.78%   +<.01%     
==========================================
  Files         479      479              
  Lines      241455   241473      +18     
==========================================
+ Hits       182991   183011      +20     
+ Misses      58464    58462       -2

Impacted Files	Coverage Δ
lib/filter.g	93.8% <ø> (-0.22%)	⬇️
src/opers.h	100% <100%> (ø)	⬆️
src/opers.c	94.85% <100%> (+0.01%)	⬆️
src/stats.c	94.69% <0%> (-0.2%)	⬇️
src/objset.c	84.82% <0%> (+0.22%)	⬆️
hpcgap/lib/hpc/stdtasks.g	63.93% <0%> (+0.51%)	⬆️

[markuspf]

Not a fan of the name extras, but with the lack of a better name, I won't stand in the way of this being merged.

[fingolfin]

Updated. Turns out that tests were failing due to an actual bug revealed by this PR: CanEasilyDetermineCanonicalRepresentativeExternalSet was declared as an attribute, but should have been a property. It is used for a method installation, but only in an and-filter, like so:

InstallMethod( \=, "xorbs with canonicalRepresentativeDeterminator",
  IsIdenticalObj,
  [IsExternalOrbit and CanEasilyDetermineCanonicalRepresentativeExternalSet,
   IsExternalOrbit and CanEasilyDetermineCanonicalRepresentativeExternalSet],
  0,
...

Which GAP silently accepted; the resulting filter then was IsExternalOrbit and HasCanEasilyDetermineCanonicalRepresentativeExternalSet, i.e., not at all what was intended...

I already found similar problems in some packages:

• homalg, see Fix use of attributes instead of their testers in method filters homalg-project/homalg_project#205
• xmodalg, see Turn IsEquivalence{Head,Tail} and IsXModAlgebraConst into filters gap-packages/xmodalg#25
• qpa, see Turn IsDirectSumOfModules into a pure filter gap-packages/qpa#16

@alex-konovalov perhaps you could run package tests against this PR before we merge it? It might reveal additional similar bugs in further packages.

[fingolfin]

Since this breaks various packages, there are two options:

1. We wait with merging this until all affected packages have a patch released.
2. I update this PR to only print a (big and fat) warning) for the abuse, but otherwise accept it as before; then once all packages are fixed, we turn that back into an error.

Option 2 is a bit more work, but it has the advantage that it reduces the likelihood of new instances of this broken behavior being introduced. OTOH, I am not sure how big the likelihood for that is...

[ChrisJefferson]

If 2 isn't too much work, it quite appeals, because it also means this doesn't get lost.

[olexandr-konovalov]

This is the full list of packages where problems occur (some of they may be cause by dependencies): - homalgtocas, io_forhomalg, linearalgebraforcap, localizeringforhomalg, matricesforhomalg, modulepresentationsforcap, modules, qpa, ringsforhomalg, sco, simpcomp, toricvarieties, xmodalg. Perhaps simpcomp is not yet looked at.

[fingolfin]

I rebased this, and for now dropped the commit which tightened the rules for AND-ing filters. Hence this PR could be merged now.

I'll put the removed commit into a new PR and/or will make a PR which just produces a warning for "bad" and-filters.

[fingolfin]

@alex-konovalov as far as I could tell, all those packages fail due to one of homalg, qpa or xmodalg. The latter two already merged the fixes, so it's mainly waiting for @mohamed-barakat or @sebasguts to merge the homalg fix and release that.