Re: [Sbcl-devel] (typep "public" '(simple-array (unsigned-byte 8) (*)))

[Chun T. (binghe) <bin...@gm...>]

Thanks for reply, I learnt a lot.

For my case, I meat this function type declare:

(ftype (function (ber-output-buffer simple-base-string &optional ber-tag) t)
	ber-write-string)

When "public" be passwd into this function, type error happend. I have to 
change simple-base-string to simple-string to bypass this.

I think the question I actually wants to know is WHY

(typep "public" '(simple-array base-char (*)))

is NIL? Character is not number or (unsigned-byte 8), now I know this.

And this information is just useful:

* (type-of "public")
(SIMPLE-ARRAY CHARACTER (6))
* (typep "public" '(simple-array base-char (*)))
nil

But in CLISP and LispWorks, I both get different answer from SBCL:

CLISP:
[1]> (type-of "public")
(SIMPLE-BASE-STRING 6)
[2]> (typep "public" '(simple-array base-char (*)))
T
LispWorks:
CL-USER 1 > (type-of "public")
SIMPLE-BASE-STRING
CL-USER 2 > (typep "public" '(simple-array base-char (*)))
T

So how to explain this? Is it a just-in-SBCL behavior?

On Friday 04 August 2006 05:44, Christophe Rhodes wrote:
> "Chun Tian (binghe)" <bin...@gm...> writes:
> > I can't understand why SBCL say:
> >
> > *  (typep "public" '(simple-array (unsigned-byte 8) (*)))
> > NIL
> >
> > Why?
>
> There are two possible low-level representations of the string
> "public" in SBCL.  One is, conceptually,
>
>    [(s-a base-char (*))|            6|p|u|b|l|i|c|\0]
>
> and the other is
>
>    [(s-a character (*))|            6|      p|      u|      b|      l|     
> i|      c|     \0]
>
> where the header indicates the type of the object, the next word
> indicates the length in lisp objects, and then there is a payload of
> the data itself.  When performing typep, the data is completely
> irrelevant: only the type of the array itself is relevant.
>
> The types (simple-array character (*)) and (simple-array base-char
> (*)) are disjoint from each other, and are additionally disjoint both
> from (simple-array (unsigned-byte 8) (*)) and from the simple-vector
> type.  The first is simple: in Common Lisp, octet-sized unsigned
> integers are not characters; the objects have distinct identities.
> The second is more subtle, and has to do with array upgrading, but is
> relatively simple in the picture of low-level representations above:
> the simple-vector #(#\p #\u #\b #\l #\i #\c), which is a simple-array
> of dimension one containing only characters, is nevertheless not of
> type (simple-array character (*)), because its representation is
>
>   [simple-vector|       6|     p|     u|     b|     l|    i|    c]
>
> (and this makes a difference, because I can set an element of the
> above to something which is not a character, but I cannot do that to a
> string.)
>
> I hope that helps somewhat.  It might be worth reading carefully the
> CLHS on the character, string and array types if you have any
> remaining confusion.
>
> Cheers,
>
> Christophe