Excuse me for this long message -- I reply to the reply to my message,
and to make things celar I quote extensively both.

I said:

>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"

Martin Schoenert says:
>> Actually this will work in GAP 3.2, but it probably should not be relied
>> upon to work in later releases.
>>
What does this mean?

>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?

Martin says
>> I beg to differ. The vector space of dimension 0 *over a given field* is
>> a perfectly valid object. But if we represent vectors in such a vector
>> space by lists of length zero we have way to find the field this vector
>> lies in.
>>
>> Why is this a problem? Well, what is the scalar product of two empty
>> vectors? Zero, of course. But which zero? The integer zero, or the
>> zero from a finite field (but of which characteristic), or the zero
>> polynomial over some ring? This is basically the problem. We have no
>> way to find a field for such an empty vector (and thus the zero).
>>

This answer seems to me unnecessarily confused. It seems to reinforce my
point that the design of GAP in this area has not been well thought
out. It is possible to adopt different viewpoints of the situation:

-pure object-oriented: everything has a type, then a vector is
necessarily a vector of something, and Martin's criticism is fully
valid; also the design of GAP is then terribly flawed since this type
is not explicitely present in the object vector, which is thus mostly
unusable.

-functional: a unique data model (list) serves a variety of purposes.
Type information is given by context. This is the viewpoint I have
adopted to try to make sense of the design of GAP. Then the problem
raised by Martin does not exist: we don't have to find the type of
an empty object, but the type the context requires, if any:
e.g.:
- add a (possibly empty) vector to a number:
if the vector is nonempty, use the type of the vector's elements
otherwise that of the number.
- scalar product of two empty vectors: no type information given by
context, it is reasonable to give an error. It would be very useful,
though, to have as answer an object which could serve as zero in a
variety of fields and rings.
- TriangulizeMat([]):
no type information given by context, but none required either,
since result is empty.
- And now the big one:
IsVector([]):
The context clearly requires 'true' !