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 GAA26207; Thu, 27 May 2004 06:34:01 +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 GAA26013 for ; Thu, 27 May 2004 06:34:00 +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 i4R4XvSH031342; Thu, 27 May 2004 06:33:58 +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 i4R4Xsk2021081; Thu, 27 May 2004 14:03:55 +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: <607E17A0-AF2E-11D8-9582-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> Content-Type: text/plain Message-Id: <1085632433.32106.93.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 27 May 2004 14:33:54 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 40B56FB5.000 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 predicate:01 permissions:01 symlinks:01 basename:01 isomorphism:01 assertion:01 pathname:01 9660:01 glebe:01 semantics:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Thu, 2004-05-27 at 02:04, Damien Doligez wrote: > On May 26, 2004, at 17:50, skaller wrote: > > > This is mathematically an ill formed statement. > > > > You cannot say P(x), when x doesn't exist, > > for a predicate P. That could lead to a contradiction. > > And yet... You can open a file that doesn't exist. No you can't. You can call the open function with a string for any string. For some strings a file will be opened. For other strings no file is opened, you get an error. If I call open on 'fred' 'joe' and 'max' on my system I will get an error in all three cases because I do not have any 'fred' 'joe' and 'max' files. So based on the behaviour of 'open' for those strings, what can we say about the semantics of the Filename module which constructed those strings? I'm sure you'd agree nothing can be said: either Xaviers 'equivalent' definition applies and the strings are equivalent because open has the same behaviour for all three, or, his definition does not apply and in BOTH cases the his definition is inadequate because clearly we'd agree these strings are not in any way equivalent -- certainly IF certain files existed such that the three open's all worked, we'd find a non-equivalence. Opening a file also depends on permissions, and symlinks ... So my conclusion is that Xaviers definition is a bad one precisely because it does depend on the underlying filesystem .. whereas Filename module itself is filesystem independent. So my belief is that Filename semantics ought to be specified directly in terms of the strings manipulated. Even though the *intent* may be to gain a particular behaviour opening files. In particular, concat "" x can generate "./" ^ x sometimes? Certainly dirname "x" can generate ".". I found that surprising. I actually expected: assert (x = concat (basename x) (dirname x)) and wrote code that depended on this isomorphism. Belatedly I find this assertion doesn't hold. I'm surprised. However I'm not claiming the behaviour is wrong, but that it isn't clearly specified what actually happens in the terms needed to make the Filename module as useful as it should be. In particular 'equivalent files' definition is of no use to me, because pathname components almost never refer to files. -- 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