From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id MAA08961; Sat, 29 May 2004 12:01:19 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id MAA09343 for ; Sat, 29 May 2004 12:01:17 +0200 (MET DST) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i4TA1DSH021814; Sat, 29 May 2004 12:01:15 +0200 Received: from [192.168.1.200] (ppp114-11.lns1.syd3.internode.on.net [150.101.114.11]) by smtp3.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i4TA1Bk2064583; Sat, 29 May 2004 19:31:11 +0930 (CST) Subject: Re: [Caml-list] unix.chop_extension From: skaller Reply-To: skaller@users.sourceforge.net To: Damien Doligez Cc: caml-list In-Reply-To: <7A9822AA-B14B-11D8-962F-00039310CAE8@inria.fr> References: <1085429093.6065.336.camel@pelican.wigram> <20040526110508.A17806@pauillac.inria.fr> <1085567689.25587.202.camel@pelican.wigram> <8026DB99-AF18-11D8-99ED-00039310CAE8@inria.fr> <1085586637.32106.45.camel@pelican.wigram> <607E17A0-AF2E-11D8-9582-00039310CAE8@inria.fr> <1085632433.32106.93.camel@pelican.wigram> <5A5E8594-B0C6-11D8-962F-00039310CAE8@inria.fr> <1085772889.3036.70.camel@pelican.wigram> <7A9822AA-B14B-11D8-962F-00039310CAE8@inria.fr> Content-Type: text/plain Message-Id: <1085824870.3036.249.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 29 May 2004 20:01:10 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 40B85F69.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 chop:01 sourceforge:01 2004:99 damien:01 permissions:01 distinctions:01 filenames:01 chop:01 bug:01 pathname:01 filenames:01 stdio:01 stdio:01 basename:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sat, 2004-05-29 at 18:37, Damien Doligez wrote: > More precisely, two names are equivalent if all file-system > operations give the same result and side effects when called > with either name. Right: this is a much more complete definition. However it is still wrong :) For example: I have no write permission on the file system, so I can't open_out any files. It also isn't entirely clear how you would actually *measure* 'same result' in all cases -- normally this is obvious, but there will be nasty cases: the problem is that it is the nasty cases that are at issue here. opening x and ./x isn't the same thing on Unix due to permissions distinctions? My experience on ISO C++ committee suggests this: The kind of definition you're giving is considered *motivation*. We want to consider two filenames equivalent 'roughly in the sense of the operational behaviour on an actual file system'. But whilst it provides motivation, such a definition can't be used as a normative specification. It just isn't abstract enough or independent enough of vagaries of some actual file system. So instead we're forced to define the semantics entirely in terms of the actual string operations, and instead of promising behaviour on an existing file system, state it as an intended consequence of the specification. EXAMPLE: chop_extension doesn't do what I expect. But there is no problem with it actually meeting its specification. There is no bug in it. However, the specification does not satisfy the motivation so Xavier might actually change it. I would argue the specification here is of the correct kind, and if the function is changed, the reasoning will be that the specification doesn't match user expectations .. not that there is a problem with deciding what the function actually does, or whether the implementation is correct. I know this sounds pedantic. However the definition in terms of strings is actually more useful: for example I can use the functions to manipulate pathname components such that I have strings which are never intended to correspond to filenames. Of course, I will usually intend that *eventually* I'm constructing filenames. But even that isn't always the case: in flxcc program I have to synthesise a module name from a filename. The module name is closely related to the filename, but isn't allowed to have non-identifier characters inside. I translate weird characters such as '.' '/' etc to '_'. For this purpose clearly: stdio.h and ./stdio.h are not equivalent. I've spent the last two days dealing with this issue, which arose simply because I didn't consider that concat (dirname x) (basename x) might not produce a filename equal to x: clearly the equivalence of names isn't enough for me here: I need equality. I have had to fix this by throwing out leading './' .. I also have no idea if, for example dirname might include a trailing '/' or not. Again, it matters, because I need to more processing than what Filename module supports: I'm left with the choice of (1) "do the whole thing yourself" or (2) "guess at what strings Filename module actually produces" and write some implementation dependent code.. :( I'm doing (2) at the moment but will probably move to (3) use Sylvain de Gall's fileutils module. -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners