Issue WITH-STANDARD-IO-SYNTAX-READTABLE Writeup

Issue:          WITH-STANDARD-IO-SYNTAX-READTABLE

References:     CLtL2 pp.565-6

Related issues: DATA-IO

Category:       CLARIFICATION

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

  later.


  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

  WITH-STANDARD-IO-SYNTAX expansion.


Proposal (WITH-STANDARD-IO-SYNTAX-READTABLE:X3J13-MAR-91):


  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).


Proposal (WITH-STANDARD-IO-SYNTAX-READTABLE:DISALLOW-MODIFICATION):


  Specify that results are undefined if the readtable object provided by

  WITH-STANDARD-IO-SYNTAX is modified.


Rationale:


  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

  anyway.


Performance impact:


  None.


Benefits:


  Another X3J13-introduced crack in the language is caulked.


Esthetics:


  Bill Ackerman told me some twenty years ago: "Lisp would be the

  perfect computer language, except that it has IO."


Discussion:


  Haflich recommends adoption.