[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Issue: PATHNAME-STREAM (Version 5)



In this version, I explicitly disallow synonym streams (and two-way,
echo, string, broadcast streams), and explicitly allow streams created
with open and with-open-file. I enhanced the discussion section, and
added a reference to p. 417  "the name returned represents the name used
to open the file, which may not be the actual name of the file".

I'm actually puzzled now as to whether it is legal to do with Xerox
Common Lisp does, which is only remember the TRUENAME of a stream once
the stream is open. The language on p. 417 seems to imply that it is
necessary also to remember the pathname supplied to open. Clarification?


!
Issue:         PATHNAME-STREAM

References:    PATHNAME (p.413), also the introductory text right above
               it on the same page.
               Derived references: 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 4 by Masinter  8-Oct-87 (explicitly only open)



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-ONLY:

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. It is an error
to attempt to obtain a pathname from a stream created with
MAKE-SYNONYM-STREAM, 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. 

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.

Adoption Cost:

Since the proposal says only "is an error" rather than "signals an
error", no implementations need change.

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: 

Is a synonym stream whose target is an acceptable stream also
acceptable? This proposal says no: the clarification is to extend the
restriction expressed on p. 417 of CLtL ("a stream that is or was open
to a file") back to cover all of the functions that take pathname
arguments. Only streams that were created given pathnames are required
to have pathnames accessable.

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