Subject: Re: strings and characters From: Erik Naggum <firstname.lastname@example.org> Date: 2000/03/16 Newsgroups: comp.lang.lisp Message-ID: <email@example.com> * 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.