From ...
From: Erik Naggum <erik@naggum.no>
Subject: Re: strings and characters
Date: 2000/03/16
Message-ID: <3162223661729749@naggum.no>#1/1
X-Deja-AN: 598423010
References: <ey3hfe73nm4.fsf@cley.com> <3162184639382952@naggum.no> <ey38zzj2fn8.fsf@cley.com>
mail-copies-to: never
Content-Type: text/plain; charset=us-ascii
X-Complaints-To: newsmaster@eunet.no
X-Trace: oslo-nntp.eunet.no 953236020 14047 195.0.192.66 (16 Mar 2000 19:47:00 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: 16 Mar 2000 19:47:00 GMT
Newsgroups: comp.lang.lisp

* Erik Naggum
| strings _always_ contain a subtype of character.  e.g., an implementation
| that supports bits will have to discard them from strings.  the only
| array type that can contain all character objects has element-type t.

* Tim Bradshaw
| I don't think this is right -- rather I agree that they contain
| CHARACTERs, but it looks like `bits' -- which I think now are
| `implementation-defined attributes' -- can end up in strings, or at least
| it is implementation-defined whether they do or not (2.4.5 says this I
| think).

  trivially, "strings _always_ contain a subtype of character" must be true
  as character is a subtype of character, but I did mean in the sense that
  strings _don't_ contain full character objects, despite the relegation of
  fonts and bits to "implementation-defined attributes".  that the type
  string-char was removed from the language but the attributes were sort of
  retained is perhaps confusing, but it is quite unambiguous as to intent.

  so must "the only array type that can contain all character objects has
  element-type t" be true, since a string is allowed to contain a subtype
  of type character.  (16.1.2 is pertinent in this regard.)  it may come as
  a surprise to people, but if you store a random character object into a
  string, you're not guaranteed that what you get back is eql to what you
  put into it.

  furthermore, there is no print syntax for implementation-defined
  attributes in strings, and no implementation is allowed to add any.  it
  is perhaps not obvious, but the retention of attributes is restricted by
  _both_ the string type's capabilities and the stream type's capabilities.

  you can quibble with the standard all you like -- you aren't going to see
  any implementation-defined attributes in string literals.  if you compare
  with CLtL1 and its explicit support for string-char which didn't support
  them at all, you must realize that in order to _have_ any support for
  implementation-defined attributes, you have to _add_ it above and beyond
  what strings did in CLtL1.  this is an extremely unlikely addition to an
  implementation just after bits and fonts were removed from the language
  and relegated to "implementation-defined attributes".

  I think the rest of your paranoid conspiratorial delusions about what
  "horrors" might afflict Common Lisp implementations are equally lacking
  in merit.  like, nothing is going to start spitting Unicode at you, Tim.
  not until and unless you ask for it.  it's called "responsible vendors".

| The only place it will matter is network transmission of data, and I
| don't see why normal compression techniques shouldn't deal with that.

  then read the technical report and decrease your ignorance.  sheesh.

#:Erik, who's actually quite disappointed, now.