Re: [Caml-list] unix.chop_extension

[skaller <skaller@users.sourceforge.net>]

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