[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: BUG-MACLISP at MIT-MC
- Subject: eoffn
- From: David C. Plummer <DCP at MIT-MC>
- Date: Sat, 13 Jun 81 16:29:00 GMT
- Original-date: 13 June 1981 12:29-EDT
(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
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.