[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "completely wrong"
- To: JAR at MIT-MC
- Subject: Re: "completely wrong"
- From: Robert W. Kerns <RWK at MIT-MC>
- Date: Sat ,16 Aug 80 21:23:00 EDT
- Cc: LISP-FORUM at MIT-MC
Date: 15 August 1980 14:58-EDT
From: Jonathan A. Rees <JAR at MIT-MC>
cc: ALAN, LISP-FORUM
Re: character objects & randomness
Date: 14 August 1980 23:18-EDT
From: Robert W. Kerns <RWK at MIT-MC>
Would you change the MacLisp #/ to generate "character objects"
(symbols)? That would be an amazing loss. If we are only talking
about NIL, then I can live with it.
As in my previous note, this is somebody's brain bubble.
Nobody, absolutely nobody, has ever suggested to my knowledge
making #/ generate "character objects".
Kerns, you are completely wrong that no one has suggested a different
meaning for #/. Steele proposed over a year ago that #/ return
"characters," which on systems that provoided them would mean
"character objects," but would otherwise probably mean "fixnums."
(Please read MC: NIL; CHPROP >.) I have been pushing this for months.
(I agree with Alan that Maclisp should NOT provide character
objects as such. But adherence to a character standard is an
independent issue from that of the existence of character objects.)
Hey, the context was the discussion, not "has ever suggested it anywhere", and
I have already acknowledged that CWH had suggested it in the discussion and I
was wrong. Inaccurate. Full of shit. Whatever. I am aware that the idea was
brought up a year-and-a-half ago or whenever, and laid to rest. I would like
to lay it back to rest. (The specific idea the #/ and TYI return CHAROBS).
[Also, I have read CHPROP several times. Your wording seems to imply that you
have been trying to get me to read it for months. I don't think that is what
you intended to imply, but the ordering of your words implies it.]
Jonathan's note points out a problem with CHPROP -- it uses the term "character
object" to denote whatever representation of a character you're using, a
fixnum, symbol (ugh) or whatever. This conflicts with the meaning that I think
everyone in this discussion uses (at least most of the time) of a special
datatype just for characters. If I'm wrong, it just proves the point;
confusion results. But as JAR has pointed out on many occasions, it doesn't
actually require that a given machine implement a special datatype; you can use
fixnums if you want to. If you read it carefully it carefully defines
"character object" for the purpose of the paper. It is a "standard", and it
takes pains to be LISPM compatible, MacLisp compatible, etc. I add my voice to
JAR's in urging people to read and adopt it.
Date: 16 August 1980 19:20-EDT
From: Daniel L. Weinreb <DLW at MIT-AI>
Subject: character objects & representation issues
To: RWK at MIT-MC
cc: LISP-FORUM at MIT-MC
Ah. I see. You mention to motivations for character objects; one
works fine in "my" proposal (the one I construed out of what I think
GLS is saying; I take no credit), but the other has problems.
First, you want character objects for debugging, so that when you see a
capital A you can tell that it is a capital A rather than a 101 octal.
With "my" proposal, you do indeed get this, so long as you do your
debugging in NIL rather than on the Lisp Machine. I don't think
anyone has objections to this.
Secondly, you want character objects to print differently. Presumably
a capital A prints as #/A, rather than as 101. This would not work in
"my" proposal. If you ran the portable FOOBAR on the LispM, and it
prints a data structure, and then you run FOOBAR in NIL and it reads it
back in, then character objects can get converted to fixnums. I don't
see any solution to this problem, other than to meekly suggest that
maybe it is just not a very common thing. Code that wants to print
character for human eyes can be made portable by going through a FORMAT
control option whenever printing character objects, rather than ever
using PRINT directly.
If the information as to what's a character and what's a fixnum is lost, no
amount of TECO-MADNESS-FORMAT-TWIDDLY-CONTROL-STRING can fix it back up.
Anyway, I have stated (several times, but it got lost in the verbiage) that
I do not think #/A should return anything othr than 101. ~A is the
representation for a character object (or #~A if you like). Too much code
already expects #/A to be a fixnum. But of course, if you run portable FOOBAR
on the LispM you can't expect to get all the features of running in NIL. But
only two things would be hurt by it: Human eyes, and transporting to someplace
with a different character set. As you say, not too important.
So anyway, I'll run and shout "CHAROBS WIN, CHAROBS WIN!", but if the LISPM
people don't want them, it's pretty clear I won't sit in a hole and cry.
But I think that we DO have a crying need for a standard like MC:NIL;CHPROP >.