[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: PATHNAME-STREAM (Version 4)
- To: CL-Cleanup@sail.stanford.edu
- Subject: Re: Issue: PATHNAME-STREAM (Version 4)
- From: Masinter.pa@Xerox.COM
- Date: 9 Oct 87 14:07 PDT
- In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message of Fri, 9 Oct 87 12:25 EDT
> Oh, also, a synonym stream whose target is an acceptable stream is
also acceptable, right?
I think not. I think the idea is to push the specification described by
the language on p. 417 ("The pathname argument may be a pathname, a
string or symbol, or a stream that is or was open to a file") back to
cover more generally all of the functions in CL which take pathname
arguments, rather than the weaker specification of p. 413 ("Any argument
called pathname in this manual may actually be a pathname, a string or
symbol, or a stream.")
If you hand a stream to a function that expects a pathname, does it
coerce it to (pathname stream) or to (truename stream)?
What is the difference between (pathname x) and (parse-namestring x)?
What are the constraints that (pathname stream) has to follow, e.g., if
you do an open the result, should the stream have the same data?
The reason why synonym streams are suspect is that I presume that
(pathname stream) should be time invarant, e.g., you should get the same
pathname given the same stream no matter when you execute it. Following
synonym streams would violate that invarant.