I think this amounts to a design decision then.

A vector of NIL can not actually hold an object of type character or anything that would reasonably construed as a sensible subtype of character envisioned by the myriad proposals on characters.  'extended-character' was supposed to augment 'base-char', not diminish it. A string must be able to hold elements from a repertoire that includes at least standard-char, which NIL does not, and then base-char is more than that, ... up to 'character' which is "top" of the sub-lattice.
In a historical context, the debate was about acknowledging existence of points in the type lattice between no-bits-no-font-attributes-minimal and everything-plus-bits-and-fonts; not about a screwy empty set of characters.
I'll grant that wishful thinking on my part does not make it so and that the current approach is legitimate.

That said, something like my patch is still correct except that zero-length (vector nil) should print as two empty quotes, and positive length vectors should print using the mechanism of the patch, which is essentially #.(make-array)



On Mon, May 19, 2014 at 7:59 PM, Richard M Kreuter <kreuter@progn.net> wrote:
Douglas Katzman writes:
> I'm not sure of the fundamental reason that (vector nil) must be a subtype
> of string, or, if it must, I don't see a fundamental reason it has to print
> with string quotes.  Could someone explain whether the first consideration
> - its string-ness - is a design choice vs requirement?

The type STRING is defined as the union of all 1-d arrays whose actual
element type is a subtype of CHARACTER. (See the dictionary entry for
STRING.)  So since NIL is a subtype of CHARACTER, (ARRAY NIL) is a
subtype of STRING.

> The following expressions are equivalent - all tautologically true.
> "for all x, if x is of type nil then x is of type character"
> "for all x, if x is of type nil then x is of type BIT"
> "for all x, if x is of type nil then x is of type (unsigned-byte 8)" etc.
> So (vector nil) can be a bit-vector, can't it?

It can't. BIT-VECTOR is (VECTOR BIT), and as compound type specifiers,
VECTOR (and ARRAY) only include arrays whose actual element type is the
result of type upgrading. (IOW, BIT-VECTOR isn't defined as arrays whose
actual element type is the union of all subtypes of BIT.)

As for printing, if you take the position that printing a non-empty
array requires implicitly accessing the elements, then probably the
consequences are undefined for trying to print it.

In fact SBCL used to do this when made to print a multidimensional array
of type NIL:

* (print (make-array '(1 1) :element-type nil))


debugger invoked on a SB-KERNEL:NIL-ARRAY-ACCESSED-ERROR:
  An attempt to access an array of element-type NIL was made.  Congratulations!
See also:
  The ANSI Standard, Function UPGRADED-ARRAY-ELEMENT-TYPE
  The ANSI Standard, Section 15.1.2.1
  The ANSI Standard, Section 15.1.2.2

That was under 1.0.8.something; 1.1.17.something errors differently for
the same case.

--
Richard