#

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

Copyright 1996-2005, LispWorks Ltd. All rights reserved.