From: Marco A. <ma...@cs...> - 2008-02-25 13:47:52
|
HI, just one last mail on the subject. Then I will shut up. On Feb 21, 2008, at 16:00 , Richard M Kreuter wrote: > Marco Antoniotti writes: >> On Feb 20, 2008, at 21:33 , Richard M Kreuter wrote: >>> "Nikodemus Siivola" writes: >>>> >>> (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. >> >> Again: which ones and how? > > Clisp signals an error in PROBE-FILE whenever stat() fails and sets > ERRNO to anything other than ENOENT on Unix. I haven't checked it on > Windows. This is one data point. LW*, Allegro, CCL, and, I bet, others, work differently. > PROBE-FILE was added to CLtL1 from an early LispM API whose documented > interface was to signal an error in all cases except the one where the > directory exists and the file does not, so systems derived from the > MIT > LispM would probably signal an error here too. ... long historical review elided ... We know that the Lisp Machines did everything and more, some of which right and some of which wrong. >> If you want to distinguish these, you are in non-portable land, >> unless you make up a portable library. I have no problem having this >> signalled by the use of a qualified name in the code. I have >> problems special casing SBCL in code I try to write for more than one >> implementation. > > As has come up several times in this thread, > > (1) Using PROBE-FILE is usually the wrong thing in a program anyway: > the file system can change between PROBE-FILE and any subsequent > attempt to use a file, and OPEN, LOAD both take IF-DOES-NOT- > EXIST > arguments that can cause those routines to fail in controlled > ways. Fine. > > (2) Most of the ways that I argue PROBE-FILE should signal an error > are ways that any immediately subsequent attempt to open or > create > a file will fail (the directory part of the pathname names a > nondirectory file, permission denied on the directory, symlink > loops). So not very many programs will avoid these errors > anyway. This is debatable, w.r.t. "current practice". We can debate whether we know enough of the "current practice", but that's the way it is. > > (3) Other implementations can, do, and have had PROBE-FILE signal > errors in various cases, so if you should ever find yourself > porting your program to such an implementation, you'll have to > deal with this variation in what implementations may > conformingly > do. Yes. But. Right now you can write programs that are "portable". You are arguing that your proposed changes should already be taken care of by portable programs, I am arguing that your changes *will* cause more grief to programs that worked "portably" until today. ... >> I program in Common Lisp, not at the POSIX level, and, up to now, >> PROBE-FILE behaves nicely on most implementations I checked. I.e. it >> implements the all-or-nothing semantics. > > The problem with forming a model of what the language is supposed > to be > by looking at what some implementations do is that implementations can > converge by accident (or some can emulate others, I suppose). In the > case of PROBE-FILE, I think there's reasonable evidence that it was > intended by the standardizers to signal errors in various cases I'm > arguing for, and certainly to be permitted to signal errors in these > cases. Yes. But. "Converging implementations" do work nicely because they set the users' expectations. You are proposing to break this IMHO, settled, interpretations of the standard. I would *love* to have more precise error subclasses for a number of things. > >>>>> (2) Users can want compatibility with other implementations. >> >> Let me rephrase this. Users *do want* compatibility with other >> implementations. At least I do. > <snip> >>> 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. >> >> But this is the crux of the problem. You want to make SBCL more >> unlike the others (AFAIS). This is, IMHO, no good. > > You cut some of the rest of what I said > > 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. > > Now, what can it possibly mean to be compatible with the details of > other implementations? Implementations already differ on the > semantics > of PROBE-FILE: > > * Clisp signals errors in various cases. > > * Allegro doesn't seem to resolve symlinks in PROBE-FILE. > > * SBCL says that a dangling or self-referring symlink is its own > truename, but OpenMCL and Allegro return NIL from PROBE-FILE in this > case. > > * Until 1.0.14, SBCL's truename resolution was a rather haphazard > thing, > which didn't always resolve all symlinks (it was quite difficult to > describe in english, in fact). But presumably it was conforming, > and > other implementations (CMUCL?) might have similarly confusing > notions > of truename resolution. Consequently, programs that use PROBE- > FILE or > TRUENAME to get a truename and then use some pathname > manipulations to > produce another pathname (e.g., merging with a pathname > having :UP in > the directory), can end up naming different files across > implementations that vary on what a truename is. > > And there are probably other details I'm not thinking of. Of course there are. It never ends. But this all thread started with the following (probe-file "/foo/not-a-directory/bar.lisp") Most implementations so far (CLisp excluded) return NIL. AFAIU, the proposal is to make SBCL break ranks with most implementations. > So ISTM that what other implementations conformingly do this week > is no > good guideline for what SBCL should do; though I think that these > other > implementations do serve as a reasonable proof-by-example of the > variation that is permissible among conforming implementations, and so > the constraints on what a truly portable program may do. The counter argument is that by providing yet another variation, SBCL would not provide such a good example. >>> 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. >> >> At a certain point CLisp came (still does to some extent) with a >> chapter in its manual: "How CLisp implements the ANSI standard". You >> can still dig out the flames that The Naggum threw Bruno Haible on >> C.L.L. on the issue (rightly so). > > Do you dispute that Clisp's current PROBE-FILE behavior is conforming? Never said that. It may have come out badly. My point is that there are different dimensions of interpretations of the CLSH. > If you don't, then the space of conforming implementations includes > implementations that signal errors in PROBE-FILE. IMO, that's all > there > is to the question "What can a CLHS-portable program rely on from > PROBE-FILE?" > >> You may be as disgusted as sometimes I am about the strict separation >> of language and underlying OS that is enforced pretty much everywhere >> in CL, but that does not allow you to be incompatible only because >> POSIX evolved somewhat differently. > > No, you're wrong on all counts. I'm willing to collaborate with other > SBCL developers on details, but I do not recognize any other > requirement > to be compatible with other implementations on any detail not in the > standard. In my opinion, it is a /virtue/ of the fact that we've a > multiple implementation language that different implementations can go > different ways. Let's put this to a vote. My opinion is that of a user of SBCL *and* of LW (plus other implementations as well). Conformity of behavior among implementations and conformance to the CLHS are *both* very important to me. It is the difficulty of leaving in a multi- implementation world. >> Let me be clear on this. If you convince ACL, LW, CMUCL, ECL, CLisp, >> ABCL, and the various implementors of other CL (I am sure I forgot >> someone; oh yes; Roger Corman, of course) to implement the PROBE- >> FILE and :APPEND semantics as you like them, then by all means go >> ahead and do it. But - right now - SBCL would become incompatible >> with other implementations and this is not a good thing (IMHO). > > I think we disagree about the nature of the CL implementation market. > Implementations differ on details; that's what it means to be a > multiply-implemented language. Implementors are not required to > emulate > each other on unspecified details. Yes, but if they do they make *my* life easier. The Java, C# or Python/Perl/Ruby/SLDJ programmer has a much easier life in this respect. > Programs that must port among > implementations need to be careful about things. > > In any case, I've already agreed to go along with whatever Nikodemus > wants PROBE-FILE to do. (Note that he and I both think PROBE-FILE > should error in "permission denied" cases, so SBCL will still be > unlike > other implementations in that detail.) AFAIC, "unlike other implementations" is bad as far as other implementations do things "correctly" and converge. > (As for :APPEND, I think you're overlooking some of the details in > that > thread. SBCL has done :APPEND in the unusual way since approximately > forever, so I've tried to explain how SBCL's behavior can be > defended as > conforming, in case other SBCL developers wanted to retain it. I also > explained in my writeup that there are various reasons not to have > :APPEND be O_APPEND, and compatibility is among those reasons. I > have a > preference, but I don't care terribly much about :APPEND, so I've > tried > not to push my preference on that detail, which I consider to be quite > minor.) Probably. I guess I never dusted that particular corner. Yet, the gist of the discussion is just the same. W.r.t. the example that appeared in the thread, there is a consensus among several implementations that the combination :APPEND with the two-argument FILE-POSITION should not cause surprises. Cheers -- Marco Antoniotti |