From ... From: Erik Naggum Subject: Re: strings and characters Date: 2000/03/16 Message-ID: <3162232362158363@naggum.no>#1/1 X-Deja-AN: 598657942 References: <3162184639382952@naggum.no> <3162223661729749@naggum.no> <3ZaA4.45$Hp4.998@burlma1-snr2> mail-copies-to: never Content-Type: text/plain; charset=us-ascii X-Complaints-To: newsmaster@eunet.no X-Trace: oslo-nntp.eunet.no 953278779 2203 195.0.192.66 (17 Mar 2000 07:39:39 GMT) Organization: Naggum Software; vox: +47 8800 8879; fax: +47 8800 8601; http://www.naggum.no User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.5 Mime-Version: 1.0 NNTP-Posting-Date: 17 Mar 2000 07:39:39 GMT Newsgroups: comp.lang.lisp * Barry Margolin | Isn't (array character (*)) able to contain all character objects? no. specialized vectors whose elements are of type character (strings) are allowed to store only values of a subtype of type character. this is so consistently repeated in the standard and so unique to strings that I'm frankly amazed that anyone who has worked on the standard is having such a hard time accepting it. it was obviously intended to let strings be as efficient as the old string-char concept allowed, while not denying implementations the ability to retain bits and fonts if they so chose. an implementation that stores characters in strings as if they have null implementation-defined attributes regardless of their actual attributes is actually fully conforming to the standard. the result is that you can't expect any attributes to survive string storage. the consequences are _undefined_ if you attempt to store a character with attributes in a string that can't handle it. the removal of the type string-char is the key to understanding this. #:Erik