English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
[Caml-list] unix.chop_extension
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-05-27 (04:34)
From: skaller <skaller@u...>
Subject: Re: [Caml-list] unix.chop_extension
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

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