# Re: #\EOF ... Yes, again.

• To: KMP at MIT-MC, LISP-FORUM at MIT-MC
• Subject: Re: #\EOF ... Yes, again.
• From: Alan Bawden <ALAN at MIT-MC>
• Date: Fri ,26 Sep 80 01:40:00 EDT

OK. lets have #\eof. Nobody has to use it, and it might make some
compatability easier to achieve.  But, it is in no way elegant:

Date: 25 SEP 1980 2300-EDT
From: KMP at MIT-MC (Kent M. Pitman)

Argument: #\ should return only representations of characters.

Answer: So should TYI and TYIPEEK. Over time, however, we have found it
useful, especially when dealing with compiler optimizations related
to fixpdls, to return an eof designator, -1. If it's good enough
for TYI and TYIPEEK, it's good enough for me.

A character is something that you can put in strings and pnames.  You
can TYO it.  You can hold down the meta key and type it.  #\eof fits
none of these descriptions.  So it must be that #\eof isn't a
character.  This makes it different from everything else that a
#\<foo> can be.

Argument: All TYI's and TYIPEEK's return -1 at eof; why not just use that?

Answer: (1) All TYI's and TYIPEEK's return #o101 for "A" being typed, but
#/A was thought to be more readable.

Do I believe what I read here?  I thought that you wanted to have #/
and #\ return character objects.  And I thought that you wanted to
write code that workes on an EBCDIC machine?

(2) If people change the representation of characters, as the
LispM people have found it useful to do, negative numbers might
want to acquire an interpretation as characters. Do you want
to break code that does (TYI STREAM -1) and which will then
perhaps perceive a premature end of file.

Nobody will ever make this mistake (making -1 a character) and live.

(3) No manual for any existing Lisp documents that -1 is not a
part of the possible character set. Nor does any manual document
that TYI returns -1 at end of file. The fact that it just happens
to annoys me. I want a documented standard.

Gee, It really isn't documented is it!  (I haven't checked LISP NEWS yet,
it is probably there, but that is a pretty poor place for documentation.)
(I don't follow the logic here anyway.)

Argument: Why not do (SETQ EOF -1) and reference #.EOF instead of #\EOF.

Answer:	(1) #.EOF doesn't supply visually as much info as #\EOF.

Agreed.  Also it seems pretty offensive to give the symbol EOF a value.

(2) It's maybe now easy but unless conventions are adopted, I
don't see any reason why it won't degenerate, over the years,
into:
(SETQ EOF #+LISPM   SI:EOF-REPRESENTATION
#+NIL     *:EOF-FIXNUM
#+MACLISP -1)
or something silly like that. Saying DEFCONST instead of
SETQ doesn't make it any less awful. The annoying part is
having system dependencies at all.

Well, no matter what, there is gonna hafta be something like this
SOMEPLACE.  I guess you must mean that people shouldn't be forced to
write that at the beginning of their code.  I agree.

... If you don't grant this, then you require me to always know
*some* information about the mapping from characters to fixnums. I
have to know the shape of the set of valid characters so I can
choose a character that's not in it.

I claim that if you have an abstraction which is 98% complete, then you
haven't really bought yourself anything. ...

Well, first let me remind you that I started this by saying that #\eof
is ok by me.  (caseq (tyi) (#\space ...) (#/A ...) (#\eof ...)) looks
almost right (*).  But: I also remind everybody that it is IMPOSSIBLE
to be 100% character representation independent.  (Remember #\lambda
and #\backspace and #^H ??  They are all EQ in MacLisp so you had
better be carefull not to use two of them in the same context!)  So
perhaps we move from 98% to 99%, you still have to have *some*
information about the mapping no matter what.  And you have bought
yourself something (even at 98%!)

(*) Of course, due to stubbornness on the part of the LispMachine people
this code won't run.  They refuse to bite the bullet and swallow
caseq, insisting that I should use a selectq macro and lose any
possible benefits from chomplr's better understanding of caseq.
Then again, the MacLisp people could let caseq take fixnums and
other objects mixed as keys, and then I could let selectq expand
into caseq and not use caseq in my code.  But as it stands I must
use both and supply my own caseq for the LispMachine.  *SIGH*
compatability!