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

[Alan Bawden <ALAN at MIT-MC>]

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!