Re: [Sbcl-devel] Arrays of the empty type

[Douglas K. <do...@go...>]

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 <kr...@pr...>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
>