Issue WITH-OPEN-FILE-STREAM-EXTENT Writeup

Issue:           WITH-OPEN-FILE-STREAM-EXTENT

References:      WITH-OPEN-FILE

                 WITH-OPEN-STREAM

                 WITH-INPUT-FROM-STRING

                 WITH-OUTPUT-TO-STRING

Related issues:  WITH-OPEN-FILE-SETQ

Category:        CLARIFICATION

Edit history:    v1, 13 Feb 1991, Sandra Loosemore

                 v2, 11 Mar 1991, Sandra Loosemore (two proposals)

                 v3, 26 Mar 1991, Sandra Loosemore (fix typos)

Status:          v3 (proposal DYNAMIC-EXTENT) accepted by X3J13, Mar 1991


Problem description:


  CLtL says that the streams created by WITH-OPEN-STREAM, 

  WITH-INPUT-FROM-STRING, and WITH-OUTPUT-TO-STRING should be regarded

  as having dynamic extent.  It is not clear whether "dynamic extent"

  is being used here in a technical sense to mean that it is valid for

  the expansion of these macros to include a DYNAMIC-EXTENT declaration

  for the variable(s) bound to the stream.


  The description of WITH-OPEN-FILE says nothing about whether the

  stream it creates has dynamic extent.  It probably should inherit

  whatever restrictions are placed on WITH-OPEN-STREAM, so you can 

  implement it that way.


  There are two proposals, DYNAMIC-EXTENT and INDEFINITE-EXTENT.


Proposal (WITH-OPEN-FILE-STREAM-EXTENT:DYNAMIC-EXTENT):


  Clarify that the streams created by WITH-OPEN-STREAM,

  WITH-INPUT-FROM-STRING, WITH-OUTPUT-TO-STRING, and WITH-OPEN-FILE

  have dynamic extent in the technical sense of the DYNAMIC-EXTENT

  declaration.  The extent of the stream ends when the form is exited.


  Rationale for proposal DYNAMIC-EXTENT:

 

    If we don't mean the technical definition of DYNAMIC-EXTENT, we

    might as well not say anything about dynamic extent.



Proposal (WITH-OPEN-FILE-STREAM-EXTENT:INDEFINITE-EXTENT):


  Specify that the streams created by WITH-OPEN-STREAM,

  WITH-INPUT-FROM-STRING, WITH-OUTPUT-TO-STRING, and WITH-OPEN-FILE

  have indefinite extent.


  Rationale for proposal INDEFINITE-EXTENT:


    It has been suggested that the mention of "dynamic extent" in CLtL

    was really a sloppy way of saying that the stream would be closed

    after the dynamic extent of the body was exited.


    It is better for the language to take the conservative point of view

    and make objects generally have indefinite extent, leaving it up to

    users to declare which things they want to be more ephemeral.



Current Practice:


  I don't know.


Cost to Implementors:


  None (DYNAMIC-EXTENT declarations are optional).


Cost to Users:


  Probably small, for either proposal.  It's possible that some people

  do things like:


    (truename (with-open-file (stream ...) ... stream))


  but it's not clear that these things are now portable anyway.


Cost of non-adoption:


  The language specification will be vague.  Implementations might 

  be prevented from making a minor optimization.  Users may encounter

  portability problems.


Performance impact:


  Adoption of proposal DYNAMIC-EXTENT will permit the stream objects 

  to be stack-allocated by default.


Benefits:


  The cost of non-adoption is avoided.


Esthetics:


  Consistent use of "dynamic extent" terminology is a good thing.


Discussion:


  Loosemore thinks either of the two proposals would be an improvement

  over the status quo.