When dealing with gap-system/gap/issues/5334 (where test code from the guava package helped to fix a bug in GAP), I noticed a few problems with related code in the file lib/codeops.gi of the guava package.
There are \in methods that take a list of codewords or a code as the first argument (see the ApplicableMethod output shown below). The correct GAP operation for expressing this relation would be IsSubset (with reversed argument ordering). Note that methods installed with requirement IsList for the first argument are applicable also in the situation where the first argument is a codeword, and these methods return false in this case; in these situations, these methods do not cause problems only because other methods have higher ranks. I think it is confusing to "misuse" the operation \in for IsSubset questions.
The \in methods for an object in IsCodeword and a code with certain properties (IsCode, IsLinearCode) have lower rank than more general methods for a vector and a vector space, but the methods for IsCodeword seem to be more efficient. It would make sense to "rank up" these methods. Here is an example in GAP 4.12.2.
gap> V:= WholeSpaceCode( 5, GF(2) );;
gap> v:= GeneratorsOfVectorSpace( V )[1];;
gap> meth:= ApplicableMethod( \in, [ v, V ], 1, "all" );;
#I Searching Method for in with 2 arguments:
#I Total: 117 entries
#I Method 65: ``in: for vector and free left module that is handled by a nice basis'' at /.../lib/basis.gi:1258 , value: 33
#I Skipped:
#I Method 66: ``in: for vector and fin. dim. free left module'' at /.../lib/modfree.gi:83 , value: 32
#I Skipped:
#I Method 69: ``in: method for codeword in cyclic code'' at /.../pkg/guava/lib/codeops.gi:1435 , value: 25
#I Skipped:
#I Method 73: ``in: method for codeword in linear code'' at /.../pkg/guava/lib/codeops.gi:1413 , value: 23
#I Skipped:
#I Method 80: ``in: method for codeword in unrestricted code'' at /.../pkg/guava/lib/codeops.gi:1389 , value: 17
#I Skipped:
#I Method 101: ``in: method for list of codewords in unrestricted code'' at /.../pkg/guava/lib/codeops.gi:1399 , value: 6
#I Skipped:
#I Method 107: ``in: for a domain, and an element'' at /.../lib/domain.gi:280 , value: 5
#I Skipped:
gap> V:= WholeSpaceCode( 5, GF(2) );;
gap> v:= GeneratorsOfVectorSpace( V )[1];;
gap> i:= 4;; for x in [ 1 .. 10000 ] do meth[i]( v, V ); od; time;
33
gap> i:= 1;; for x in [ 1 .. 10000 ] do meth[i]( v, V ); od; time;
115
When dealing with gap-system/gap/issues/5334 (where test code from the guava package helped to fix a bug in GAP), I noticed a few problems with related code in the file
lib/codeops.giof the guava package.\inmethods that take a list of codewords or a code as the first argument (see theApplicableMethodoutput shown below). The correct GAP operation for expressing this relation would beIsSubset(with reversed argument ordering). Note that methods installed with requirementIsListfor the first argument are applicable also in the situation where the first argument is a codeword, and these methods returnfalsein this case; in these situations, these methods do not cause problems only because other methods have higher ranks. I think it is confusing to "misuse" the operation\inforIsSubsetquestions.\inmethods for an object inIsCodewordand a code with certain properties (IsCode,IsLinearCode) have lower rank than more general methods for a vector and a vector space, but the methods forIsCodewordseem to be more efficient. It would make sense to "rank up" these methods. Here is an example in GAP 4.12.2.