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