From ... From: Erik Naggum Subject: Re: strings and characters Date: 2000/03/21 Message-ID: <3162628727290082@naggum.no> X-Deja-AN: 600651360 References: <3162223661729749@naggum.no> <3ZaA4.45$Hp4.998@burlma1-snr2> <3162232362158363@naggum.no> <3162302923332864@naggum.no> <868zzhjjgb.fsf@g.local> <3162477100853468@naggum.no> <8666uioc8n.fsf@g.local> <3162506888111902@naggum.no> <86hfe1qor6.fsf@g.local> mail-copies-to: never Content-Type: text/plain; charset=us-ascii X-Complaints-To: newsmaster@eunet.no X-Trace: oslo-nntp.eunet.no 953686789 3314 195.0.192.66 (22 Mar 2000 00:59:49 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: 22 Mar 2000 00:59:49 GMT Newsgroups: comp.lang.lisp * Gareth McCaughan | Well, this is an argument. To paraphrase (and I'm sure you'll tell me if | this is misleading), "The behaviour of implementation- -defined things is | implementation-defined". The trouble is that this proves too much -- if | the implementation-defined-ness of character attributes other than the | CODE means that implementations are allowed to throw them away when | characters are stored in strings, I don't see why it shouldn't also mean | that implementations are allowed to throw them away when you bind them to | variables, or put them in lists. you don't see that? well, I can't help you see that, then. let me just reiterate what I have previously said: a regular array with element-type t can hold any character object. if you insist on being silly, however, there's nothing I can do to prevent this from going completely wacky. | No, I don't want the standard to prescribe implementation-defined | behaviour. I just don't think that "implementation-defined | attributes" means "mysterious things whose semantics may be | entirely inconsistent with everything in this standard". that is your interpretation, Gareth, and I claim it's unsupported by facts, but ever more supported by silliness and "I don't see why"'s. now, I do see how you are reaching your conclusion, I just don't accept that you have refuted the one thing I'm still claiming: that the standard _requires_ there to be a specialized array (string) that must be able to hold all character objects. since you're going into silly mode, I can only guess that you don't understand my argument and have to ridicule it. and let me just say that an implementation that chooses to allow strings to hold all attributes is obviously just as conforming as one that only has strings that holds the code attribute. | I don't know why you think I expect the standard to be perfect. because you use it as the basis of proofs that you expect to be universally valid without recognizing your own interpretative work (including omitting irrelevant points that seem irrelevant to you) in constructing them. the confidence in perfection required to do this is quite staggering. | I do think that my interpretation is more natural than yours, and that | the amount of error the standard would have to contain if your view were | right is considerably more than the amount it would have to contain if | mine were right. Both of these (plus the fact that it seems on the whole | to have very few errors) lead me to prefer my view to yours. this, however, is a valid line of argument. I just happen to disagree. | That observation is there for a picky pedantic reason: that I want to | make it explicit not only that there are things capable of holding | arbitrary characters, but that those things are actually strings in the | sense defined in the standard. and I have already pointed out that the union type does not contain the individiual type that is _required_ to hold all characters. to get that, you have to upgrade the element-type to t. | Clearly you consider my deduction flawed. You haven't, though, said | what's wrong with it. yes, I have. I have pointed out that it ignores several important factors that affect how you can interpret the standard. in particular, that the requirement you come up with _adds_ additional burden to an implementation that decides to continue to support implementation-defined attributes above and beyond what it needed to do before they were removed from the standard. this is clearly a serious mismatch between intent and expression, and we need to understand the intent behind the standard when it seems to say something that isn't very smart. | That's borne out by Barry Margolin's recollections of the discussions of | the standardising committee. for some reason, I have yet to see those posted to the newsgroup. if you could mail them to me, I'd be much obliged. | My interpretation of the standard doesn't make it require anyone to add | support for the removed features. now, this is just plain ridiculous or unbelievably ignorant. strings in CLtL1 were made up of string-char elements, not character. string-char explicitly excluded fonts and bits attributes. now that string-char has been removed, and you claim strings have to contain the whole character type, and not only a subtype, as I claim, the string that used to be able to contain only the code attribute, now has to be able to contain characters _with_ implementation-defined attributes, as well. this is NOT A QUIET CHANGE to the implementation -- it has a really major impact on system storage requirements. this fact, however, is recognized in the reader for strings (which may dump attributes at will, however they wound up in the characters read from an input stream) and intern (which may also dump them at will, regardless of how they could get into the string to begin with). clearly, you don't understand the implications of what you interpret the standard to say if you don't understand that it forces an implementation to _add_ support for a feature the standard effectively deprecates. #:Erik