« prev · plain text · next »       2000 · Erik Naggum comp.lang.lisp archive       search · random

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

* Gareth McCaughan <Gareth.McCaughan@pobox.com>
| 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