On 2/9/08, Richard M Kreuter <kreuter@...> wrote:
Prologue: When I say "portable program" below, I mean "program using
portable operations and classes", not the CLHS Glossary definition:
the set of programs dealing with the file-system or pathnames that are
portable in the true CLHS sense of the word is much smaller then the
programs that can be expressed using portable CLHS vocabulary, but
which might not work everywhere. The way these "portable" programs
generally fail to work is by signaling an error where one was not
expected -- and so no harm is done when they are run in a conforming
implementation that doesn't support whatever behavior was expected.
> > TRUENAME has basically two responses: "definitely exists", and
> > "something else".
> > PROBE-FILE has basically three responses: "definitely exists",
> > "definitely does not exists", and "something else".
> I agree that this would be a conforming definition, but ISTM that it's
> handier to divide the cases into "definitely exists", "definititely
> doesn't exist, but everything else about the query was okay",
> "anything else". It just makes programs simpler to be able to write
I think this is really the core question here, and everything else is
Reasons why I think NIL = "definitely does not exists" is better then
"definitely does not exist + some extra conditions":
* Nothing in PROBE-FILE documentation leads users to expect the
latter. Even if there are classes of programs which are easier to
write using the latter interpretation, those programs are not
portable, as implementations are allowed to return NIL as well. As
bizarre as it is, programs which expect NIL for "/not-a-directory/foo"
are portable -- they just don't work everywhere. Programs which expect
an ERROR for that are unportable.
* I repeat my assertion that signalling an error is not something user
programs can deal sanely with. Well, "not sanely" is an overstatement,
but "not very usefully" at minimum seems true: the only thing a
handler can do there is punt to "something funny here" case -- but
writing code to figure out if the error is in the file-system,
implementation, or the pathname is not an exercise I would care to
engage in, or recommend to others.
Internally we can use CAREFUL-PROBE-FILE, or similar, that checks for
those extra conditions we care about, but I don't think implementation
convenience should override user concerns here.
> [**] I do take compatibility concerns seriously, and I did bring up this
> change to PROBE-FILE a month prior committing it. IIRC, the only
> feedback was from a few people in #lisp, and this feedback was positive
> (though at the time I wasn't proposing having PROBE-FILE error when the
> directory doesn't exist in an ENOENT way).
I was, and am, generally speaking more then happy with the changes.
The only thing I am concerned about with here is "signal errors from
PROBE-FILE in more cases then we used to, even if it would be legal
and correct to return NIL".
My assertion above that these errors are not useful may seem to be at
odds with my own predilection for specific condition classes, but
there is (I hope) a method to my madness here:
* In cases where we must signal an error for which no useful (useful =
specific enough that the program can tell what is going on without
having a human read the error message) condition class exist, using an
implementation specified one makes it possible to write unportable
programs that do interesting things. Portable programs are unaffected.
This is good.
* In cases where we may signal an error, but don't have to, and not
signaling an error is sane and portable programs can be written using
that behavior, and when no useful portable condition classes exist, if
we choose to signal the error we reduce the number of interesting
things portable programs can do. This is not good.
It seems to me that we can have best of both worlds here by signaling
specific conditions from TRUENAME (and making
FILE-DOES-NOT-EXIST-ERROR one of them), and signaling as few
conditions as possible from PROBE-FILE.
(defun careful-probe-file (pathspec)
(defun probe-file (pathspec)
((or file-does-not-exist-error not-a-directory-error) ()
;; anything else?
It is not the end of the world if PROBE-FILE signals an error for
pathnames it believes suspect, but I would prefer that in that case my
claims about the price portable programs pay for this are refuted, or
that we make a policy decision that conformance and implementation
specific features are more important then conformance and support of