WIP: Fixes for vector spaces with DimensionOfVectors(V) = 0 (DO NOT MERGE)

[fingolfin]

[This is motivated by #2117 resp #2121; in particular, it fixes #2117)
Given a vector space V with DimensionOfVectors(V) = 0, e.g. V:=GF(5)^0, we currently
have Zero(V) = []. This commit makes the following snippets work:

• Coefficients(Basis(V), [])
• Position(Enumerator(V), [])
• [] in V

Especially the last point requires a rather nasty hack: By definition, "[a] collection in GAP consists of elements in the same family"; and any vector space V in GAP is such a collection, yet its only element, the empty list [], is not in the correct family. This already is strictly speaking a bug, and forcing \in to work regardless could equally be described as a "fix" or as "making things even worse".

So all in all I am conflicted about merging this... But what is the alternative? For vectors over small fields, we could realize #2121 and make empty compressed vectors safe to use, but that doesn't solve e.g. the case of Rationals^0.

[ThomasBreuer]

I agree with the statement by @fingolfin that it is not clear
whether changing the behaviour of empty lists in the context of domains
means to improve or to worsen the system.

Let us look at some more examples.

• Once [] is established as an element of each vector space GF(q)^0,
  one may expect that GF(2)^0 = GF(3)^0 yields true,
  since two domains are equal if they have the same sets of elements.
  (Note that no [] object appears in this comparison question.)

• Once one has accepted the above equality,
  one may expect also that [] is contained in
  Intersection( GF(2)^0, GF(3)^0 ).
  And if this intersection shall be represented as a domain
  (which is recommended in general)
  then which characteristic shall it have?

• Two compressed lists of length zero in different characteristics
  should be equal, by the general rule that two lists are equal
  if and only if their entries are equal at all positions.
  (Currently = returns false in this situation.)
  Thus the problem is really one about empty lists and not just about
  [] objects.

One can change the behaviour of empty lists in particular situations,
in order to use (or misuse?) it in some code,
but one cannot get a consistent behaviour simply because the underlying
rules are not consistent.

I think the only clean way out of this problem would be
to forbid domains containing empty lists.
Adding more support for empty lists as elements of domains
will uncover inconsistencies in other places.

In practice,
I would suggest to avoid situations like the one from which the discussion arose
(that of extended vectors formed from length zero vectors, #2117).
A special treatment of the zero dimensional case looks perhaps less elegant
but would be safe.

[fingolfin]

Regarding empty compressed vectors comparing equal: The "ideal" fix for that would be to make compressed vectors and matrices not lie in IsList. But I am afraid this might easily open new up new problems... Still, it's something I'd love to try for the GAP 4.10 cycle.

But yeah, for now, we need to deal with the specific problem at hand.

BTW, the thing I don't like about adding special cases for zero dimensions everywhere is not so much that it's less elegant, but rather that it's a game of whack-a-mole: We'll never know that we didn't miss a spot, and it's quite likely people will write new code which lacks special cases for the zero-dimensional case.

[stevelinton]

I think the right way to do this is just to retire the existing compressed vectors entirely in favour of somethign based on cvec and/or meataxe64 which have never been designed to lie in IsList. Cleaning up all the crud in the existing compressed vectors which is only there because of compatibility with lists is probably more work than writing something better.

However, I think that means switching all the linear algebra and matrix groups to work via MatrixObj, which is a huge task.

[ThomasBreuer]

These changes extend the support for empty lists in the context of domains, which might encourage people to (mis)use the behaviour, and then it is likely that problems arise in other places.
I am not voting against the changes, but I do not really like them.

[fingolfin]

Just to clarify: I also don't like the changes in this PR very much. I mostly put it out here to have a better foundation for discussion.

I'll close this now, though, as I think it's clear we want to go in another direction. I added some more issues (#2148 and #2149) regarding empty vectors and possible semantics for comparing MatrixObj and VectorObj.