[HARLEQUIN][Common Lisp HyperSpec (TM)] [Previous][Up][Next]


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.


[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996, The Harlequin Group Limited. All Rights Reserved.