MatrixObj: don't force MatrixObj to be collections? Add replacement for `IsMatrix and IsFFECollColl`

[fingolfin]

In GAP, IsMatrix objects are collections. Thus a common way to install a function that only works for matrices over finite fields is to use IsMatrix and IsFFECollColl. And we also do this:

DeclareSynonym( "IsMatrixGroup", IsRingElementCollCollColl and IsGroup );
...
DeclareSynonym( "IsFFEMatrixGroup", IsFFECollCollColl and IsMatrixGroup );

But for IsMatrixObj, it seems unreasonably to me to require them to be collections.
UPDATE: Besides fundamental objections to this, I also think that the only sensible way to do that would be to consider them as collections of their entries (as we explicitly do not want to require all matrices to be lists of row vectors). But then Size (which must be implemented for collection) should return NrCols(mat) * NrRows(mat); but that would be incompatible with existing IsMatrix objects, where Size returns the number of rows.
END UPDATE

UPDATE 2: I just discovered this text in lib/matobj1.gd:

The family of an object in IsMatrixObj is the collections family of the family of its base domain.

So it seems this was an explicit goal. It still seems problematic to me. Of course we could agree to follow this, but then this still leaves the question how to deal with the requirement that collections must implement Size but also should support enumerators and iterators. Perhaps we just document that IsMatrixObj are exempt from this rule?
END UPDATE 2

I would therefore suggest that we add special filters to replace the use of IsFFECollColl and also IsCyclotomicCollColl for matrices and vectors.

Indeed, I already see these two in the library:

DeclareFilter( "IsIntVector" );
DeclareFilter( "IsFFEVector" );

Although only the former is used... anyway, we could add a few filters (whether they should be pure filters, categories, properties, ... I don't know / care too much about) and then start converting existing code to use them... Say like this:

DeclareCategory( "IsFFEMatrixObj", IsMatrixObj );
DeclareCategory( "IsCyclotomicMatrixObj", IsMatrixObj );
DeclareCategory( "IsFFEVectorObj", IsVectorObj );
DeclareCategory( "IsCyclotomicVectorObj", IsVectorObj );

DeclareCategory( "IsMatrixGroup", IsGroup );
DeclareCategory( "IsFFEMatrixGroup", IsMatrixGroup );
# TODO: perhaps we also need an `IsMatrixObjGroup` category???? seems too technical to me, though

...
InstallTrueMethod( IsFFEMatrixObj, IsFFECollColl and IsMatrixObj );

InstallTrueMethod( IsMatrixGroup, IsRingElementCollCollColl and IsGroup );
InstallTrueMethod( IsFFEMatrixGroup, IsFFECollCollColl and IsMatrixGroup );

Perhaps we can also have an IsMatrixObjCollection, and then do this?

InstallTrueMethod( IsMatrixGroup, IsMatrixObjCollection and IsGroup );

And then of course code should be added to set these filters in further situations.

[fingolfin]

Looking at it, I guess categories are the way to go, so that we can use DeclareCategoryCollections? Then we can have IsMatrixObjCollection via DeclareCategoryCollections( "IsMatrixObj" );. Of course this won't catch lists of "classic" matrices (just as the existing IsMatrixCollection doesn't catch those), but that's not to be avoided (and indeed, one of the motivations for IsMatrixObj). Then I guess we could have new method for FieldOfMatrixList and friends which apply to IsMatrixObjCollection -- or perhaps even more specialized, to IsFFEMatrixObjCollection.

Finally, note that IsPlistMatrixRep (see also PR #2973) currently creates objects which are in IsFFECollColl, by virtue of using CollectionsFamily(FamilyObj(basedomain)) to create the family.

[ThomasBreuer]

One thought about the question whether any matrix must be a collection:

Take the C-MeatAxe programs as an example.
They deal with questions about permutation modules and natural modules for matrix algebras.
A GAP interface to these programs can be implemented by creating the obvious GAP objects that point to the C-MeatAxe "generators" objects (which are typically files) plus some GAP objects that encode modules, bases etc. which are handled more implicitly by the C-MeatAxe.

It looks natural to regard a C-MeatAxe permutation as a GAP permutation and a C-MeatAxe matrix as a GAP matrix, but following GAP's rules for that causes a lot of overhead, and raises questions which do not help at all with just using the relevant functionality.
This includes questions about the family of an object, being a collection, etc., but already the question about access to matrix entries is something that causes problems because the C-MeatAxe does not really support elements of finite fields as objects. In this sense, C-MeatAxe matrices are "atomic" objects which are used to denote bases of modules or algebra elements acting on modules, without need to access matrix entries.
In order to keep the interface simple, it may thus make sense to take the viewpoint that a C-MeatAxe matrix is not a GAP matrix, and that one has to create a corresponding GAP matrix in the (hopefully few) cases where one wants to access a particular entry.
One can still provide methods for operations such as TransposedMat, but GAP operations which have no counterpart in the C-MeatAxe will not be applicable to the objects that are handled by the interface --since the objects are not called matrices, there is no promise that all these operations will work.

(Of course, one may also want to implement an alternative format of GAP matrices, using the external programs, and therefore provide methods for all matrix operations that are offered by GAP, but this is another story.)

My point in this example is the question what we want to support:
If somebody wants to provide an implementation of some matrix related functionality and wants to call the objects matrices, do we accept only "full" implementations of all operations, with all conditions on families and being collections satisfied, or would also "partial" implementations (with errors happening outside the scope of the implementation) be acceptable?

[fingolfin]

I noticed that the semigroups package introduces a property IsMatrixObjOverFiniteField which is also in this vein (CC @james-d-mitchell).