From ...
From: Erik Naggum <erik@naggum.no>
Subject: Re: strings and characters
Date: 2000/03/17
Message-ID: <3162302923332864@naggum.no>#1/1
X-Deja-AN: 598829584
References: <ey3hfe73nm4.fsf@cley.com> <3162223661729749@naggum.no> <3ZaA4.45$Hp4.998@burlma1-snr2> <3162232362158363@naggum.no> <c_sA4.70$Hp4.1824@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 953314137 10837 195.0.192.66 (17 Mar 2000 17:28:57 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 17:28:57 GMT
Newsgroups: comp.lang.lisp

* Barry Margolin <barmar@bbnplanet.com>
| But if you want a type that can hold any character, you can create it with:
| 
| (make-string length :element-type 'character)

  no, and that's the crux of the matter.  this used to be different from

(make-string length :element-type 'string-char)

  in precisely the capacity that you wish is still true, but it isn't.
  when the type string-char was removed, character assumed its role in
  specialized arrays, and you could not store bits and fonts in strings any
  more than you could with string-char.  to do that, you need arrays with
  element-type t.

  but I'm glad we've reached the point where you assert a positive, because
  your claim is what I've been trying to tell you guys DOES NOT HOLD.  my
  claim is: there is nothing in the standard that _requires_ that there be
  a specialized array with elements that are subtypes of character (i.e., a
  member of the union type "string") that can hold _all_ character objects.

  can you show me where the _standard_ supports your claim?

| In fact, you don't even need the :ELEMENT-TYPE option, because CHARACTER is
| the default.

  sure.  however, I'm trying to penetrate the armor-plated belief that the
  resulting string is REQUIRED to retain non-null implementation-defined
  attributes if stored into it.  no such requirement exists: a conforming
  implementation is completely free to provide a single string type that is
  able to hold only simple characters.  you may think this is a mistake in
  the standard, but it's exactly what it says, after the type string-char
  was removed.

  methinks you're stuck in CLtL1 days, Barry, and so is this bad imitation
  jerk from Harlequin, but that's much less surprising.

#:Erik