#

## Issue WITH-OPEN-FILE-SETQ Writeup

    Issue:           WITH-OPEN-FILE-SETQ
    References:      WITH-OPEN-FILE
                     WITH-OPEN-STREAM
                     WITH-INPUT-FROM-STRING
                     WITH-OUTPUT-TO-STRING
    Related issues:  WITH-OPEN-FILE-STREAM-EXTENT
    Category:        CLARIFICATION
    Edit history:    v1, 13 Feb 1991, Sandra Loosemore
                     v2, 11 Mar 1991, Sandra Loosemore

    Problem description:

      It isn't clear whether it is permissible for the variable bound to
      a stream by WITH-OPEN-FILE, WITH-OPEN-STREAM, WITH-INPUT-FROM-STRING,
      or WITH-OUTPUT-TO-STRING may be explicitly assigned to within the body.
      The expansion of these macros must include some code to close the stream
      after executing the body forms.  Can this code refer to the stream
      using the user-supplied variable, or must it use another "hidden"
      variable in case the user-supplied variable has been assigned to in
      the body forms?

    Proposal (WITH-OPEN-FILE-SETQ:EXPLICITLY-VAGUE):

      Clarify that the consequences of altering the values of the variables
      bound to streams by WITH-OPEN-STREAM, WITH-INPUT-FROM-STREAM,
      WITH-OUTPUT-TO-STREAM, and WITH-OPEN-FILE (by using SETQ, for example)
      are undefined.  A Common Lisp compiler may choose to issue a warning
      if such a variable appears in a SETQ.

    Rationale:

      This is consistent with what CLtL says about altering the value of
      the counter variable in a DOTIMES form.

    Current Practice:

      Lucid CL, Allegro CL, the Chestnut Lisp-to-C translator, and Symbolics
      Common Lisp all implement WITH-OPEN-FILE in such a way that the
      user-supplied variable is referenced to close the stream.

    Cost to Implementors:

      None, since this permits implementations to continue to use the
      "obvious" expansion.

    Cost to Users:

      Probably none.  Any user programs that depend on it working the other
      way are already clearly not portable.

    Cost of non-adoption:

      The language specification will be vague.  Users may have portability
      problems.

    Performance impact:

      Negligible.

    Benefits:

      Users will know what to expect and will avoid a portability pitfall.

    Esthetics:

      Doesn't look too bad.

    Discussion:

      Kent Pitman notes:

        It probably is worth mentioning that the most common abuse of this
        situation I've seen is that sometimes users will create broadcast
        streams, echo streams, etc., or even implementation-dependent
        encapsulations of the indicated stream to the opened file and then set
        it back to the indicated variable.  (Whether the later call to CLOSE
        is a good idea to do to the compound stream which results is something
        that probably varies from implementation to implementation.  This
        proposal certainly makes it more clear that users who do this are
        living on the edge.)

        Anyway, I just wanted to emphasize that the only scenario was not
        something bizarre like someone doing

         (WITH-OPEN-FILE (TEMP ...)
           (PRINT X STREAM)
           (SETQ X (+ 7 2)) ...)

Copyright 1996-2001, Xanalys Inc. All rights reserved.