FreeMonoid does not always have IsFreeMonoid

[james-d-mitchell]

When we do:

F := FreeMonoid(0);

the returned object is the free group with 0 generators, and it does not satisfy IsFreeMonoid.

What is worse is that if we take a quotient of F by the (necessarily empty) list of relations the resulting object is not in IsFpMonoid and so none of the standard attributes for an fp-monoid, like RelationsOfFpMonoid and so on, can be applied to this object. This is bad because it requires a special case in all code using quotients of free monoids that handles this (trivial) case.

It would be possible to remove the special case:

# Handle the trivial case.
if IsEmpty( names ) then
  M:=FreeGroup( 0 );
  # we still need to set some monoid specific entries to keep
  # the monoid code happy
  F:=ElementsFamily(FamilyObj(M));
  FamilyObj(M)!.wholeMonoid:= M;
  F!.freeMonoid:=M;
  return M;
fi;

in FreeMonoid (lines 221 to 230 in lib/monofree.gi) and do the same thing as is done for free groups instead:

if IsEmpty( names ) then
  G:= GroupByGenerators( [], One( F ) );

But unfortunately, every trivial monoid belongs to the category IsGroup because of:

InstallTrueMethod( IsMagmaWithInverses, IsMagmaWithOne and IsTrivial );

in line 135 of magma.gd. This is another annoying special case: the only time a monoid (of transformations, for example) that is created using the Semigroup or Monoid functions belongs in the category IsGroup in GAP is when it is trivial. If it is non-trivial, even if it defines a group mathematically, it does not belong to the category IsMagmaWithInverses. It would be better if this was consistent, and that a transformation monoid, for example, created using the function Monoid never belongs to IsGroup. This applies to several other types of semigroups too, but not, for example, to permutations (i.e. Monoid((1,2,3)) returns a group).

Supposing that we made the change so that the free monoid of rank 0 is created using

MonoidByGenerators([], One(F))

(where F is the FreeMonoidElementsFamily) because the rank of the filter IsFreeGroup is (much) higher than that of IsFreeMonoid the methods for free groups are still selected even though our (new) free monoid of rank 0 is no longer a proper free group (i.e. it does not have the necessary data structures
of a free group in GAP).

I'm not sure how to resolve this.

[markuspf]

I think maybe a useful first step is trying to disentangle the mess that is caused by filter names IsGroup, IsMonoid, and IsSemigroup.
I think if something is created using Monoid, it should always be in IsMonoid and behave like a monoid. If one wants a group, one has to prove that one has a group and supply an isomorphism (and hence a translation to a different interface to the same algebraic structure). I had a short conversation with @fingolfin about this just now, and I think we need to write out a proposal as to how we imagine this to work more cleanly without rewriting the whole library in one go.

I will try to find the time to do so.

[james-d-mitchell]

Sounds good!

I don't think these things are particularly entangled, I think everything makes sense except that FreeMonoid(0) does not return a free monoid and that preferably the line:

InstallTrueMethod( IsMagmaWithInverses, IsMagmaWithOne and IsTrivial );

should be removed from the library.

[james-d-mitchell]

This is resolved.