eoffn

[David C. Plummer <DCP at MIT-MC>]

(I would cc this to BUG-MANUAL, but that list seems to be dead.)

The documentation in   :info maclisp input ...  which describes
eoffn does not conform to practice (or vice versa). 

[for a file opened with  (open ... '(in fixnum single))]
doc: when eof is reached, the end-of-file function is called with
  two arguments...
practice: the end-of-file function gets only one argument: the
  file object. (for ascii files it gets two arguments)
doc: the second argument is the eofval made on the call to the
  reader, or nil if none was supplied
practice: in the (in ...) case, none CAN be supplied (maybe one
  should be possible), and therefore I suggest that the newly
  created second argument to the eoffn be made nil. 

This should be made more general (if it doesn't break 3.14*10^100
programs already in existence).

Also, on the same subject of (open ... '(in fixnum single))

doc: if the end-of-file function returns neither t nor nil, then
  the result is immediately returned as the value of the input.
practice: (eoffn <file object> '(lambda (x) -1))  does NOT return
  -1, it returns a number similar to 100040075056(octal). I don't
  care where this number came from, since it is supposed to be
  -1. In fact, if I try to return '(this is a list) I get 0, and
  if I try "this is a string" I get 10000075061(8). I did a
  maknum on these, and 100040075056 is FIXNUM, 0 in NIL, and
  10000075061 is SYMBOL (I don't know which string package I
  have, it doesn't matter).

Would somebody mind removing all the extra code that is necessary
to produce such bizzare results and just make it simple and
general and CORRECT !!!!!

Separate bug -- on TWENEX, as far as I can tell eoffn does not
  work for files opened for (in fixnum single). When eof is
  reached, it complains that eof is reached and does not check
  for an eoffn.