[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: PSZ at MIT-ML
- Subject: TTYSCAN troubles.
- From: ALAN at MIT-MC (Alan Bawden)
- Date: Sat, 26 Apr 80 03:57:00 GMT
- Cc: (BUG LISP) at MIT-MC
- Original-date: 25 APR 1980 2257-EST
Date: Fri, 26 Apr 80 02:26:59 GMT
Original-Date: 04/25/80 22:26:59 EDT
Subject: Re: TTYSCAN troubles. (long msg)
One solution to this kind of problem that has been proposed (and
implemented by GSB) is to abandon the notion of table-driven scanning
schemes as unworkable, and to use an "inner" call to read which is a
perfect predictor of when read will terminate on a particular string.
This is, of course, wasteful, as the read is done twice (though perhaps
some clever catch/throw scheme around the outer read could obviate the
need for it... but that's another story). Worse yet, it has the nasty
characteristic that any side-effects performed by the reader (e.g.,
interning atoms, read-time creation of data structure) are
hard/impossible to undo, and even if some stuff is typed and then rubbed
out, its effect remains.
GSB's solution is the one used by the LispMachine reader (including a
catch/throw scheme to prevent doing the read twice). No one has ever
complained about the duplication of side effect issue. I my opinion,
if you are doing some kind of non-repeatable side effect at readtime,
then you are probably doing something wrong. This solution to rubout
processing is the cleanest imaginable and it NEVER fails! (Users can
write the hairyest reader macros imaginable and it works like a
charm.) It isn't even all that expensive since it only happens during
interactive READing and never when reading from a file.
It sure is a shame that it is too late to do it the right way in MacLisp.