[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
READ flushing atom delimiters
- To: MOON at MIT-MC
- Subject: READ flushing atom delimiters
- From: JONL at MIT-MC (Jon L White)
- Date: Fri, 30 May 80 10:31:00 GMT
- Cc: (BUG LISP) at MIT-MC, INFO-LISPM at MIT-MC
- Original-date: 30 MAY 1980 0631-EDT
Date: 30 May 1980 00:23-EDT
From: David A. Moon <Moon at MIT-AI>
. . . I f the delimiter is a "useless" or "whitespace" character,
it will be thrown away, rather than being UNTYI'ed back into the stream
so that it can be TYI'ed later. This will happen regardless of whether
the symbol or number is seen at top level or is inside of an expression,
. . .
Certain programs, such as reader macros, may be broken by this. For them,
a special variable which they may bind is provided.
If READ-PRESERVE-DELIMITERS is bound non-NIL around a call to READ,
all delimiters are preserved regardless of whether they are whitespace
or meaningful characters. . . .
I would like to request a compatible change to Maclisp, to avoid
divergence and incompatibility on this point.
As it happens, GSB and I made this change to one version of a recent XLISP,
probably about version 1984 or so, but had to take it back when GSB
found he didn't have the time to accomodate his LMS and COBOL code.
What we were hoping to do was provide an additional function, say,
READ-AND-BREAK-CHAR, which would return both the item read and the
termination character. For backwards compatibility, someone may raise
an objection to not haveing a "backwards-compatible-switch" (i.e.
READ-PRESERVE-DELIMITERS), but for future use, the explicit request
to return the termination character seems like a better approach for
those very few programs which want it. Any comments?