Fix use of categories versus representations
Opened this issue · 0 comments
A category should normally not imply a representation, but this packages does this a lot, e.g. here:
DeclareCategory("IsSkewbrace", IsAttributeStoringRep);
This code means that any skewbrace type from now on must be in the IsAttributeStoringRep
representation. So if I wanted to implement a nice skewbrace subtype myself, I couldn't -- at least not while staying compatible with your package; or else I'd have to come up with my own "name" for the concept, such as IsAnotherKindOfSkewbrace
.
Instead, there should be a category which carries the mathematical implication, and a representation, which implies the category. Something like this (we also add IsDomain
in, as a skew brace is a "domain" in the GAP sense of the word (i.e., a collection with an algebraic structure).
DeclareCategory("IsSkewbrace", IsDomain);
DeclareRepresentation("IsSkewbraceRep", IsSkewbrace and IsAttributeStoringRep);
(Of course IsSkewbraceRep
isn't quite nice either, as it blocks that name for a very peculiar representation, but at least now others can also use IsSkewbrace
sensibly).
I guess one might even want to do more, and throw in IsMagma
or some such, but that's a separate issue.