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)" <binghe.lisp@...> 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
|