[HARLEQUIN][Common Lisp HyperSpec (TM)] [Previous][Up][Next]



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.

Problem description:

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



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.

Current practice:

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


Performance impact:



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.

[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996, The Harlequin Group Limited. All Rights Reserved.