Re: [Ocaml-lib-devel] Proposal : Path

[skaller <sk...@oz...>]

On Fri, 2003-11-14 at 23:58, Martin Jambon wrote:
> On Fri, 14 Nov 2003, Nicolas Cannasse wrote:
> 

> type root = Windows of string | Unix | Current_dir | Path of t
> 
> and t = { root : root;
>           virtual_path : string list }
> 
> ... and implement functions that change either the root or the 
> virtual path.

I have had this concept for some time, however it is
slightly different. I use it in interscript.

The concept is of a "mount point" which is an 
arbitrary atomic operating system dependent
prefix (usually specifying a directory),
plus a universal relative pathname convention
following Unix:

	name / name / .... / name

The universal filename is constrained -- you can NOT
represent all possible filenames on every system,
instead, every such filename is representable on
all systems.

The way this works is: the mount point is obtained
from the command line or some environment variable,
by some portable means, but it is never analysed,
so the system dependency is irrelevant to portability.

The string form of the universal filename can be used,
or an unpacked form as with 'virtual_path : string list'
can be constructed. Either form can be used for manipulation
of subdirectories or files, but it is all indepdendent
of the mount point.

Thus: in interscript you can write:

@h = tangler('src/xxx.ml')
[blah bla code to tangle out to xxx .. ]

and on the command line you write:

iscr --tangler_directory="d:\program files\silly windows\"

and the function 'make_os_filename' combines the mount
point and the universal filename to make (in this case) a Windows
filename. Thus, all filenames inside interscript work
on all platforms, even though relative Unix filenames
must be used -- precisely *because* they're used
as the universal format.

You will note you CANNOT specify an absolute path --
it is not permitted in the suffix part. In particular
no portable program is allowed to know which filesystem
it is working with.

The client program must act as if each mount point
is precisely that: the root of a file system.

With this concept, issues like:

-----------Martin--------------------->
Some problems concerning the current implementation under Linux:
1. //tmp///toto is valid and equivalent to /tmp/toto (because any
filename 
must have at least one character)
2. /../../.. is equivalent to / (which is dangerous anyway)
3. toto/ is more restrictive than toto (trailing slash indicates that
toto 
<----------------------------------------

... simply cannot arise. We dont care about the mount point 
string at all, since the program never sees it and isn't permitted to
synthesise it.

We care about the universal part, but what Linux does is irrelevant.
We can define our own rules (and I think we just ban consecutive 
slashes for example).

Finally: this mechanism requires a bit of a paradigm shift.
You need to see that splitting the notion of heirarchical 
directories and filesystems/mount points
always works when there is a portability requirement.

And post-finally <g>: one can extend the concept to include
access methods. Whence there is already a Standard
portable format, namely that used for a URL.