TTYSCAN troubles.

[ALAN at MIT-MC (Alan Bawden)]

From:     PSZ@MIT-ML
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.