From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id D2500BC6B for ; Thu, 6 Sep 2007 11:51:05 +0200 (CEST) Received: from einhorn.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l869p5XL002837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 6 Sep 2007 11:51:05 +0200 X-Envelope-From: oliver@first.in-berlin.de X-Envelope-To: Received: from einhorn.in-berlin.de (localhost [127.0.0.1]) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id l869p45q021002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 6 Sep 2007 11:51:04 +0200 Received: (from www-data@localhost) by einhorn.in-berlin.de (8.13.6/8.13.6/Submit) id l869p4u2020996 for caml-list@inria.fr; Thu, 6 Sep 2007 11:51:04 +0200 X-Authentication-Warning: einhorn.in-berlin.de: www-data set sender to oliver@first.in-berlin.de using -f Received: from dslb-088-073-111-054.pools.arcor-ip.net (dslb-088-073-111-054.pools.arcor-ip.net [88.73.111.54]) by webmail.in-berlin.de (IMP) with HTTP for ; Thu, 6 Sep 2007 11:51:04 +0200 Message-ID: <1189072264.46dfcd8841608@webmail.in-berlin.de> Date: Thu, 6 Sep 2007 11:51:04 +0200 From: Oliver Bandel To: caml-list@inria.fr Subject: Re: [Caml-list] Bug in Filename.basename? References: <20070905184538.88ada4e8.mle+ocaml@mega-nerd.com> <20070905104127.GB24323@furbychan.cocan.org> <20070905211013.b53cf46b.mle+ocaml@mega-nerd.com> <1188991526.46de922610e05@webmail.in-berlin.de> <20070905220031.5995251d.mle+ocaml@mega-nerd.com> <1189024766.46df13fed404a@webmail.in-berlin.de> <1189054365.9224.74.camel@rosella.wigram> In-Reply-To: <1189054365.9224.74.camel@rosella.wigram> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 X-Miltered: at discorde with ID 46DFCD89.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; bandel:01 in-berlin:01 bug:01 basename:01 0200,:01 bandel:01 ocaml's:01 dirname:01 basename:01 ocaml:01 ocaml:01 ocaml's:01 semantics:01 libref:01 dirname:01 Zitat von skaller : > On Wed, 2007-09-05 at 22:39 +0200, Oliver Bandel wrote: > > > The behaviour of OCaml's > > Filename.concat (Filename.dirname) (Filename.basename) > > makes sense to me. IMHO it should be done the way OCaml does it. > > You fail to understand that this requirement is ALSO > met by Posix C functions and bash. [...] But that does not mean that OCaml does not make it. So, what's the problem? > > The difference is Ocaml's function doesn't have well specified > semantics, whereas Posix is an International Standard backed > by the United Nations. Maybe OCaml later will be also ;-) BTW: specify "United Nations", it could be misleading, what you are writing. I didn't know that the UNO makes programming language standardization. > > The Ocaml manual says this: > > http://caml.inria.fr/pub/docs/manual-ocaml/libref/Filename.html > > "Moreover, after setting the current directory to dirname name (with > Sys.chdir), references to basename name (which is a relative file name) > designate the same file as name before the call to Sys.chdir. > > And that is in fact rubbish: Yes and No. > filename functionality is not > directly related to the filesystem, correct. > because the files need > not exist (or may not agree with the specified name in kind). If you read again, you can see: "references to basename (...) name designate the same file as name before the call to Sys.chdir". The term "references" might be misleading, but what is meant? Possibly the result of Sys.readdir, so this means that the names one has got from one function of the Filename module are also useful, after using Sys.chdir, because Sys.readdir gives you the basenames of the files in the dir you read. If you compare functionality of functions of a module, look, what functionality the module also offers. Looking somewhere else makes no sense. This would be ignoring the sense of modularization. Inconsistencies in one and the same module would be a reason to argue about. > > Other than this text, the Ocaml manual in fact does NOT > specify what happens if there is a trailing / character. If this is the problem, then the documentation should be more verbose. > > Posix does. So you're wrong on all counts here. > There's no excuse for Ocaml not doing one of: > > a) following the Posix rules on a Posix platform > AND saying so > b) following other rules, AND describing them The documentation then should be made more clear. But to say, that OCaml has a bug, only because it does not handle things equally like the POSIX-stuff, which btw uses C-functions.... If POSIX should be followed completely, then it also has to follow in this way: http://www.opengroup.org/onlinepubs/009695399/functions/basename.html "The basename() function may modify the string pointed to by path, and may return a pointer to static storage that may then be overwritten by a subsequent call to basename()." It may ,modify, it may not. So, I doubt this is something that you want to have in OCaml's Filename-module. If it is not mentioned that things might be modified in place, in a mostly-functional language I want to have the arguments not modified. Following POSIX here, would posbe a desaster. > > In general, a WEAK specification is good, and the Ocaml > specification here is weak: it doesn't specify what happens > if there is a trailing / character. However in THIS case > the user may be surprised at what it actually does. If this is a point that is unclear, write a note on the bugtracker, to make the documentation more clear. > > Indeed, the OP Eric was surprised! Maybe. But why to blame OCaml as buggy, if he is surprised? OCaml handles a lot of things in a different way. Or were are e.g. sumtypes in POSIX defined? I rather would argue into the opposite direction: a Unix.fork() should not give back an int, only because on Unix/POSIX this is done this way. Beter would be something like type fork_t = Parent | Child of int where int means the PID. It's too-much POSIX/Unix here, IMHO, even if it is called the Unix-module. But it's not a reason to make long discussions on it. I would like it differently, but it also is acceptable as it is. > > The fact is I AGREE WITH YOUR ARGUMENT if you would be arguing > that it is sensible to consider that since in Unix you cannot > tell if a filename refers to a directory or a non-directory file, > a SENSIBLE CONVENTION is to put a / at the end if you mean a > directory. This would be fine, to make it always this way. This would be clear then. Not all people would follow this. The advantage of making all things a file has the disadvantage that the name allone could not show us, what kind of file it is. For that reason, the filetype can be distingushed by the results of Unix.stat. > > I agree, that's sensible. But it doesn't matter. The purpose > of the Filename module is to process filenames in a way that > closely matches the normal behaviour of native functions on > the native platform That's your interpretation. The documentation of Filename-module msays: =================== module Filename: sig .. end Operations on file names. =================== That's not much ;-) > .. and the interpretation above IS NOT DOCUMENTED. In the documentation of the Filename-module I can't see that they say, they Follow POSIX. So, YOUR ASSUMPTION might be a problem. I'm happy not to have too much POSIX-behaviour inside OCaml, when for example, regarding the modified strings of the args. But maybe you would like it that way. Ciao, Oliver