#

## Issue PATHNAME-STREAM Writeup

    Issue:         PATHNAME-STREAM

    References:    PATHNAME (p.413), also the introductory text right above
                   it on the same page.
                   Derived references: TRUENAME (p.413), PARSE-NAMESTRING (p.414),
                   MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
                   OPEN (p.418), WITH-OPEN-FILE (p.422),
                   RENAME-FILE (p.423), DELETE-FILE (p.424)

    Edit History:  Version 1 by Moon 11-May-87
                   Version 2 by Masinter 29-May-87 (minor editing)
                   Version 3 by Masinter 11-Jun-87 (minor editing)
                   Version 4 by Masinter  8-Oct-87 (rewording)
                   Version 5 by Masinter  8-Oct-87 (explicitly only open)
                   Version 6 by Masinter 14-Nov-87

    Category:     	CHANGE/CLARIFICATION

    Problem Description:

    CLtL says that a stream can be used as an argument and converted to a pathname,
    but many sources or sinks of data that streams might be connected to have no
    pathnames associated with them; for example, streams created with
    MAKE-TWO-WAY-STREAM or OPEN-STRING-STREAM. For many such streams, there is no
    simple way to coerce such a stream to a pathname.

    Proposal PATHNAME-STREAM:FILES-OR-SYNONYM:

    Clarify that the use of a stream as an argument that expects a pathname (as
    described on p413 of CLtL) only applies to streams that are originally opened by
    use of the OPEN or WITH-OPEN-FILE, or to synonym streams whose symbol is bound
    to such a stream. It is an error to attempt to obtain a pathname from a stream
    created with MAKE-TWO-WAY-STREAM, OPEN-STRING-STREAM, MAKE-ECHO-STREAM,
    MAKE-BROADCAST-STREAM, MAKE-CONCATENATED-STREAM, MAKE-STRING-INPUT-STREAM,
    MAKE-STRING-OUTPUT-STREAM.

    The pathname used represents the name used to open the file. This may be, but is
    not required to be, the actual name of the file. The pathname used is the same
    as would be returned by the PATHNAME function.

    Rationale:

    This is probably what the designers of Common Lisp intended. This is the only
    thing that can be implemented without large changes to the language such as
    extending pathnames to things other than files.

    Current Practice:

    Some systems signal an error if a non-file stream is used as a pathname. Others
    return an empty pathname.

    Some implementations do not return a meaningful value for PATHNAME of a synonym
    stream.

    Adoption Cost:

    Implementations that do not currently handle PATHNAME of a synonym stream will
    have to change to allow it. Otherwise, since the proposal says only "is an
    error" rather than "signals an error", no implementations other changes are
    necessary.

    Benefits:

    The description of pathname functions will make more sense.

    Conversion Cost:

    Small: Users with code which accesses pathname components of streams in
    implementations which allow it might need to change their programs to make them
    portable.

    Aesthetics:

    Makes language a little cleaner.

    Discussion:

    The only point of disagreement on this proposal has been on the issue of whether
    PATHNAME applies to synonym streams and returns the pathname of the stream
    designated.

    This version of the proposal says yes, because CLtL p 329 says about synonym
    streams that  "Any operations on the new stream ..." and does not say anything
    about exceptions; earlier on the page the phrase "synonym streams that pass all
    operations on" is used.  This seems fairly unambiguous, although the word
    "operations" is not defined. There was a similar controversy about what CLOSE of
    a synonym stream means.

    Note that there is currently no way portable to determine whether a stream has a
    pathname available.

    The entire PATHNAME section needs work to clarify the intent and enable portable
    code. This is just a minor issue among the major ones.

Copyright 1996-2005, LispWorks Ltd. All rights reserved.