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