I hope it is not too late to ask for some small fixes for what I consider to be
a bug in the design of some gap functions. To show why I consider this feature to be a bug,
I will show some examples of programs where I had to add ugly code to get around
it -- then you can argue against me constructively by showing me how I should have
written my code.

Example 1:
Given a list l1,..lr of integers (with no holes -- recognized as a vector by Gap)
I want to construct the list (1,..,d,l1+d,...,lr+d).
So I wrote:

gap>shift:=function(l,d)return Concatenation([1..d],l+d);end;

What is the problem? This does not work when l is empty: I get

"Error, Vectors: '+' incompatible types"

Indeed, when asked:

gap>IsVector([]);
false

Is not this wrong? The vector space of dimension 0 is a perfectly valid
mathematical object -- How to represent its elements?

I had to write:

plus:=function(a,b)
if Length(a)=0 then return a;
elif Length(b)=0 then return b;
else return a+b;
fi;
end;

and use it in many places instead of '+' (and similarly for '-').
Is not this ugly (and inefficient)?

Example 2:
I need to compute an echelonized basis of the space generated by a set of vectors.
If s is this set (represented as a list of vectors), TriangulizeMat(s) works well
excepted when the set is empty:

gap>TriangulizeMat([]);
Error, ... because in the code of the function Length(mat[1]) is taken.

Would not it be easy to fix it so that TriangulizeMat([])=[] ?

Discussion:
these 2 examples seem to me a symptom of a wrong treatment of empties in GAP, which
forces to add ugly and unnecessary code to handle special cases. GAP has only one
kind of empty, the list [] (in contrast to languages like APL where an empty matrix still
may have a shape like [0,5]). This is fine with me, but then all operations which logically
should accept empty vectors(or matrices, or whatever...) should also accept [].
I cannot see any big problem with IsVector([]) being true, but it being false certainly gives me
problems.

Jean MICHEL, D.M.I., E.N.S - Paris