From: Nikodemus S. <nik...@ra...> - 2008-02-18 22:21:27
|
On 2/18/08, Richard M Kreuter <kr...@pr...> 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. :) Just a few clarifications: > > * Nothing in PROBE-FILE documentation leads users to expect the > > latter. > > Are you talking about the CLHS? We've already agreed that signaling an > error is confoming for an implementation, and so a user who doesn't > notice this is simply overlooking things. But I don't think it's > important to cater to naive readings of the standard: there's a lot one > can miss or misunderstand in the standard. 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. 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.) 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.) > But there are other problems with the idea that returning NIL promotes > CLHS-portable programs. While some implementations return NIL for cases > such as ENOTDIR or ELOOP, a program can't CLHS-portably determine > whether a pathname names a directory or names a bad symlink. For FWIW, I think ELOOP is clear FILE-ERROR: it might be that the bit that loops is symlink whose pathname were are probing -- so we cannot tell, just like with EACCESS. ...but I'm not claiming anything re other errno situations -- just thinking about ENOTDIR right now. > But maybe you're expressing a concern that a useful hierarchy of > subclasses of FILE-ERROR can't be created. Here's a quick sketch at the > problem, from things I can think of off the top of my head; if you don't > like something, let's hash out the details: I most certainly believe such a hierarchy can be built, and I would indeed like to have one. I have no quarrels with your sketch at first glance. > (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.) > (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. Cheers, -- Nikodemus |