"Nikodemus Siivola" writes:
> On 2/18/08, Richard M Kreuter <kreuter@...> wrote:
> > However, I should say up front that I am not digging in my heels over
> > this detail, and am willing to concede and have PROBE-FILE return NIL in
> > various cases, though I do think it would be better to do it the other
> > way.
> Your points are well made, and while I think it would be better the
> other way around, both are without doubt conforming.
> No matter how I argue the other point, if this makes your life in the
> stream-and-pathname-guts-of-SBCL better, then that is a strong
> argument in favor of your interpretation. ...but I still prefer mine.
I've already agreed to concede on PROBE-FILE in my last message in this
thread. It's just taking too much of my time to argue with you about
> > > * Nothing in PROBE-FILE documentation leads users to expect the
> > > latter.
> > Are you talking about the CLHS?...
> I am talking about the CLHS. I am not talking about a user missing the
> bit about errors, but rather about how this is understood:
> "An error of type file-error is signaled if the file system cannot
> perform the requested operation."
> While we have established that we can interpret "directory doesn't
> exist" to mean that the file system cannot tell us if a specific file
> or subdirectory of that non-existent directory exists, I am still
> inclined to believe that this possible interpretation doesn't occur to
> most people.
I think today's thread about :IF-EXISTS :APPEND should suffice as
proof-by-example that different readers of the standard will come away
with incompatible interpretations. So ISTM that "what possibilities
won't occur to some other reader of the CLHS?" is a minor criterion.
And again, signaling an error in exactly this case was explicitly
mentioned as a motivation for adding that language to the spec (see the
CLHS issue writeup), so I don't think you can say that nobody could get
the interpretation I've been advocating.
> This means that it is not IMO unreasonable to write code like this:
> ;;; Code to install something into a specified location, and
> ::: potentially write a default configuration.
> (defun write-config (pathname)
> (with-open-file (f (ensure-directories-exist pathname)
> :direction :output)
> (prin1 *default-config* f)))
> ;; We've checked that CONFIG doesn't have :UP or :BACK components
> (let ((path (merge-pathnames config *config-root*)))
> (or (probe-file path)
> (not *default-config*)
> (write-config path))
> and expect it to work as long as permission under *our-root* are in order.
> (By "work" I obviously mean that no FILE-ERRORs are signaled for
> missing directories by PROBE-FILE.)
Do you normally use ENSURE-DIRECTORIES-EXIST in calls to WITH-OPEN-FILE?
I rarely do, and I doubt others do so too often. If you leave out the
ENSURE-DIRECTORIES-EXIST, then the second fragment fails with the same
error under both versions of PROBE-FILE.
Also, if you want to write a file only if the file already exists, you
can use :IF-DOES-NOT-EXIST NIL or :IF-DOES-NOT-EXIST :ERROR, in which
case you don't need to PROBE-FILE first.
Finally, since other implementations can and do signal an error from
PROBE-FILE in various cases, using PROBE-FILE will actually obstruct
> Portable -- definitely not, but perfectly reasonable for "I tested it
> on implementation X, and the program should be easy to port to others:
> while it may rely on implementation specific behaviour it doesn't dip
> into internals at any point" code.
> Indeed, it is not clear to me how to write this in the presence of
> such errors without probing each directory part of the pathname
> separately -- which is just horrible. Handling a FILE-ERROR there is
> not good, because then we never learn if the permissions are wrong (or
> other nebulous bad things.)
I've tried to say this this before, maybe I didn't say it clearly
(1) Some implementations signal errors in PROBE-FILE. Therefore, your
program will not do what you want on those implementations anyway,
but will stop when it encounters the error.
(2) Other implementations return NIL from PROBE-FILE for all ways that
stat() fails, including EACCES. Therefore, your program cannot
even reliably distinguish EACCES from ENOTDIR, even if if it wants
That is, the only thing that resembles portabiltiy is to use PROBE-FILE
in different, implementation-specific ways on each implementation you
mean to target, or indeed not to use it at all.
> > (2) Users can want compatibility with other implementations. As I've
> > pointed out, some implementations do PROBE-FILE one way, while
> > others do it the other way. SBCL can't be compatible with all of
> > them, and I don't strive for precise compatibility with other
> > implementations.
> I think here CCL, Allegro, and Lispworks are reasonable comparisons,
> but I have the impressions that Clisp's take on various pathname
> issues is neither wildly popular nor very much like anything else.
> (I'm not saying that Clisp is wrong, just that as a pathname
> portability datapoint is is AFAIK quite an outlier.)
I don't want to get into a game of ranking other implementations for the
purpose of making SBCL more like some than like others. If we're agreed
that Clisp's behavior is conforming, then ISTM to be admissible as
reasonable evidence of what an implementation might do -- which also
means some future implementation that people may care about will do
things that way too.
> > (3) Finally, I think users can want SBCL to provide operators that make
> > programs convenient to write. As I've argued, having PROBE-FILE
> > return NIL only in a very specific case makes programs that need to
> > use PROBE-FILE easier to write on SBCL, because the program does not
> > need to figure out the meaning of the NIL.
> This is where I disagree. If those programs target SBCL specifically
> they can call TRUENAME and handle those specific conditions (as per
> your sketch above) they care about.
Out of curiosity, why do you think it better to rely on SBCL-specific
error classes around TRUENAME, but not PROBE-FILE?