Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: skaller <skaller@users.sourceforge.net>
To: Damien Doligez <damien.doligez@inria.fr>
Cc: caml-list <caml-list@inria.fr>
Subject: Re: [Caml-list] unix.chop_extension
Date: 27 May 2004 14:33:54 +1000	[thread overview]
Message-ID: <1085632433.32106.93.camel@pelican.wigram> (raw)
In-Reply-To: <607E17A0-AF2E-11D8-9582-00039310CAE8@inria.fr>

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


  reply	other threads:[~2004-05-27  4:34 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-24 20:04 skaller
2004-05-24 22:01 ` skaller
2004-05-25  8:46 ` Alex Baretta
2004-05-25  9:35   ` skaller
2004-05-25  9:46     ` Alain Frisch
2004-05-25 10:47       ` skaller
2004-05-25 11:51         ` sejourne kevin
2004-05-26 11:18           ` Florian Hars
2004-05-25 14:06         ` [Caml-list] Re: AAP (was: unix.chop_extension) Christophe TROESTLER
2004-05-25 13:37     ` [Caml-list] unix.chop_extension John Goerzen
2004-05-25 19:17     ` Richard Jones
2004-05-27  8:15   ` YANG Shouxun
2004-05-27  9:47     ` skaller
2004-05-26  9:05 ` Xavier Leroy
2004-05-26  9:35   ` Luca Pascali
2004-05-26  9:56   ` Remi Vanicat
2004-05-26 10:34   ` skaller
2004-05-26 13:27     ` Damien Doligez
2004-05-26 15:50       ` skaller
2004-05-26 16:04         ` Damien Doligez
2004-05-27  4:33           ` skaller [this message]
2004-05-27  4:56             ` John Goerzen
2004-05-28 16:44             ` Damien Doligez
2004-05-28 19:34               ` skaller
2004-05-29  8:37                 ` Damien Doligez
2004-05-29 10:01                   ` skaller
2004-05-29 16:02                     ` David Brown
2004-05-26 11:21   ` Alex Baretta
2004-05-26 16:43     ` Richard Jones
2004-05-27  4:48       ` skaller
2004-05-27  7:46         ` Markus Mottl
2004-05-27  9:33           ` skaller
2004-05-27 17:29       ` brogoff
2004-05-28 12:00         ` Keith Wansbrough
2004-05-28 16:43           ` brogoff
2004-05-28 17:49             ` Marcin 'Qrczak' Kowalczyk
2004-05-28 11:23       ` Alex Baretta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1085632433.32106.93.camel@pelican.wigram \
    --to=skaller@users.sourceforge.net \
    --cc=caml-list@inria.fr \
    --cc=damien.doligez@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox