References: CLtL2 pp.565-6
Related issues: DATA-IO
Edit history: Version 1, 29-Nov-90, by Haflich
Version 2, 08-Apr-90, by Pitman
(add newly worded proposal from meeting)
Status: X3J13 passed option X3J13-MAR-91 on vote of 11-1, March 1991.
Proposal DATA-IO:ADD-SUPPORT passed in June 89 added the new macro
WITH-STANDARD-IO-SYNTAX which executes a body with all the read/print
special variables bound to known values. All the prescribed binding
values are immutable objects except for *READTABLE*, which is required
to be bound to "the standard readtable."
Not addressed was the question what happens if someone modifies the
readtable inside the body, or captures the value and modifies it
If "the standard readtable" were the implementation's special copy of
the initial readtable, modifying this readtable would have the
unfortunate effect of breaking the defined behaviour of COPY-READTABLE
as a way of obtaining a fresh copy of the standard readtable.
If "the standard readtable" provided by the macroexpansion were a
single reusable copy of the standard readtable, COPY-READTABLE would
be safe, but the readtable seen successive calls to expansions of the
macro would not necessarily be the standard readtable.
If "the standard readtable" were a fresh copy of the standard
readtable obtained from COPY-READTABLE, there would be no surprises,
but the cost of consing readtables would be a disincentive to using
WITH-STANDARD-IO-SYNTAX where performance was important.
Other implementation strategies could be considered -- for example, a
readtable could record whether they have ever been modified, and entry
to WITH-STANDARD-IO-SYNTAX would create a fresh copy only if the
previously copy had been modified. But even this wouldn't be safe if
someone captured the readtable and modified it later after the
readtable had been reused for a later execution of a
Specify that results are undefined if the standard readtable is modified.
Clarify that the `standard readtable' (the one copied by COPY-READTABLE
when it is given a NIL argument, or the one to which *READTABLE* is bound
by WITH-STANDARD-IO-SYNTAX) must not be the same as the `initial readtable'
(the one to which *READTABLE* is initially bound when Lisp starts).
Specify that results are undefined if the readtable object provided by
WITH-STANDARD-IO-SYNTAX is modified.
This is ackowledgement of the status quo and makes explicit a
limitation of WITH-STANDARD-IO-SYNTAX which would not otherwise
be obvious to users.
It's unclear anyone actually implements WITH-STANDARD-IO-SYNTAX.
It's even more unclear anyone actually uses it.
It's highly unlikely anyone has ever yet written code that modifies
a readtable inside the body.
Does Genera's WITH-STANDARD-IO-ENVIRONMENT deal with this issue?
Cost to Implementors:
If ALLOW is adopted there will be some annoying changes required to
readtable implementation and readtable modifying functions if
implementors want to avoid ther overhead of copying a new readtable at
every entry to a WITH-STANDARD-IO-SYNTAX expansion.
Cost to Users:
None, assuming no user has yet violated the restriction. User code
that needs to modify a readtable is free to make an explicit copy,
but no other code needs pay the price.
Cost of non-adoption:
This is only a clarification. Modifying the readtable inside
WITH-STANDARD-IO-SYNTAX will continue to have undetermined effects
Another X3J13-introduced crack in the language is caulked.
Bill Ackerman told me some twenty years ago: "Lisp would be the
perfect computer language, except that it has IO."
Haflich recommends adoption.