CLHS: Issue WITH-OPEN-FILE-STREAM-EXTENT Writeup

#

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

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