From: Erik Naggum <e...@naggum.no>
Subject: Re: strings and characters
Date: 2000/03/16
Message-ID: <3162232362158363@naggum.no>#1/1
X-Deja-AN: 598657942
References: <ey3hfe73nm4.fsf@cley.com> <3162184639382952@naggum.no> <ey38zzj2fn8.fsf@cley.com> <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 <bar...@bbnplanet.com>
| 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