Subject: Re: strings and characters
From: Erik Naggum <erik@naggum.no>
Date: 2000/03/17
Newsgroups: comp.lang.lisp
Message-ID: <3162302923332864@naggum.no>

* 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