Indeed, one of us must be confused.

[Kent M. Pitman <KMP at MIT-MC>]

No, I think I understood fully what you meant. Nothing in your reply is in
conflict with my original message. I suggest that it is you who misunderstood
me... My turn now to be less vague.

In any case like the LispM where vectors aren't there, then there would be
cases of the code in this form:

    (COND ((VECTORP obj) ...branch X...)
	  (T ...branch Y...))

Now, it may in some sense seem arbitrary whether branch X or Y is taken, so
long as it's predicatable, but I argue that there are good reasons why someone
should want it to take branch Y in the case where vectors are not being
represented.

The first is that on the LispM there really will not be any vectors and that
intuitively the right thing is for nothing to claim to be a vector. I think
the other arguments follow from this but let me lay them out.

The next reason is that one cannot debug branch X fully on a system which
does not have vectors. You can write code like:

    (COND ((VECTORP X)
	   ...simple code which needn't know about fill pointers...)
	  (T
	   ...code which might hack fill pointers if they exist...))

For some applications, this code will function incorrectly on an X which
is 1-D but has a fill pointer because it may be relevant to some kinds
of computation that X does have a fill pointer. Consider:

    (DEFUN SET-STREAM-RUBOUT-HANDLER-BUFFER (STREAM BUFFER)
      (COND ((VECTORP BUFFER)
	     (ERROR "Buffer must have all the hairy features of arrays!"))
	    (T
	     (SET-STREAM-RUBOUT-HANDLER-BUFFER-INTERNAL STREAM BUFFER))))

This is a useful error check to put in portable code and would be
thwarted by VECTORP returning T on non-vectors. Further, one -could- at
least debug branch Y correctly because it would have to worry about the
case of fill pointers. It might have to go to more work than was needed
on a few inputs, but there are no cases where I think a drastically
wrong thing would happen. The reason for this is clear:  Even in systems
with VECTORs, it is possible to construct 1-D arrays which have all the
properties of VECTORs except VECTORness itself.

Hence, in an environment like the LispM, this is exactly what you have.
A thing with all a VECTOR's properties except one -- VECTORness. And since
you can't reliably tell what was made with a VECTOR property and what wasn't,
the right thing is to make the default in the safe direction, which I claim
is to assume they are not the simple case unless you have proof.

-kmp

ps Note that there is a third alternative which is to require that 
   implementations not supporting vectors at least support something 
   which is identifiable as a VECTOR. This could be done by storing a 
   special marker in an array leader, by creating a hash table of all
   vectors, or whatever. I do not advocate this idea, but I do point it out.