[m-rev.] for review: library changes for `mmc --make' on Windows

[Simon Taylor]

On 19-Jun-2003, Peter Moulder <Peter.Moulder at infotech.monash.edu.au> wrote:
> On Sun, Jun 15, 2003 at 12:05:42AM +1000, Simon Taylor wrote:
> 
> > +	% '/' on Unix systems and '\' on Microsoft Windows systems.
> 
> Any opinions as to whether to say '\' or '\\' or `\' or backslash ?
> '\' jars a little, but I'm not sure that it isn't the best option.
> I'd lean towards `/' and `\'.
> 
> > +	% dir__split_name(PathName, DirName, BaseName).
> > +	% Split a filename into a directory part and a filename part.
> > +	% Fails for root directories or relative filenames not
> > +	% containing a directory separator.
> 
> I think the usual thing people want from something outputting DirName
> and BaseName is p(X, dirname(X), basename(X)), and I think such a
> procedure should be provided;

Why?

> though such a predicate could be called
> dir__dirname_basename if we also want something with the proposed
> split_name semantics.  (Off hand I can't think of a case where a program
> would want the proposed semantics.)

If the user wanted to split a path into a list of path components.

split_into_components(PathName) = split_into_components_2(PathName, []).

split_into_components_2(PathName, Components0) =
	( split_name(PathName, DirName, BaseName) ->
		split_into_components_2(PathName, [BaseName | Components0])	
	;
		[PathName | Components0]
	).

> I think that if we use the names dirname and basename then we should try
> to conform to a fairly authoritative standard for these names, say

In theory, yes, but in practice a lot of these standards aren't
particularly well thought out.
 
>  http://www.opengroup.org/onlinepubs/007904975/functions/dirname.html
>  http://www.opengroup.org/onlinepubs/007904975/functions/basename.html
 
> (However, the existing implementation doesn't for a few cases like
> "/", "", or when PathName has trailing slashes.)
> 
> I'm no expert on Windows filename semantics.  Would basename("C:\\") =
> "\\" be reasonable?

I don't think that's particularly useful behaviour.
I'd suggest the following on Windows:

% Root directory.
dir.split_name("C:\\", _, _) :- fail.

% Relative path
dir.split_name("C:foo", "C:", "foo").
dir.split_name("C:", _, _) :- fail.

dir.split_name("\\foo", "\\", "foo").
dir.split_name("\\", _, _) :- fail.

dir.split_name("", _, _) :- fail

dir.split_name("foo", _, _) :- fail.
dir.dirname("foo") = ".".
dir.basename("foo") = "foo".

The documentation would be as follows.

	% dir__split_name(PathName, DirName, BaseName)
	% Split a filename into a directory part and a filename part.
	% Fails for root directories and filenames not containing
	% directory information.
	% Trailing slashes are removed from PathName before splitting.
:- pred dir__split_name(string, string, string).
:- mode dir__split_name(in, out, out) is semidet.

	% dir__dirname(PathName) = DirName
	% Extract the directory part of the given filename.
	% Fails for root directories.
	% Returns "." for filenames not containing directory information.
	% Trailing slashes are removed from PathName before splitting.
:- func dir__dirname(string) = string is semidet.

	% dir__basename(PathName) = BaseName
	% Extract the filename part of the given filename.
	% Fails for root directories.
	% Trailing slashes are removed from PathName before splitting.
:- func dir__basename(string) = string is semidet.

> I think the documentation for the dir foldl preds should say something
> about order.  For the recursive versions, it's worth specifying that
> parents are processed before their children.  For children, perhaps
> state that there are no order guarantees.  I'm tempted to specify that
> it's the same order as given by the underlying platform's
> directory-reading function.  (This has useful properties for many
> filesystems, in some cases even lexical ordering.)

I'd rather not give any guarantees about ordering -- this is meant
to be a high level interface.

> check_for_symlink_loop: I wonder whether it would be better to use
> set_bbbtree rather than list, on grounds of optimizing for worst case;
> the usual case has acceptable performance for either representation.

How deep are you expecting the directory trees to be? In the common
case (where there are no symlinks), using a list will be faster.
 
> The name `follow_symlink' to me suggests that it acts recursively (finds
> the ultimate destination if it's a symlink to a symlink to a ...),
> whereas the implementation is not recursive.  The predicate
> documentation doesn't clearly specify -- though I would guess that
> `pointing to' isn't recursive.

I've changed it to io__read_symlink.

Simon.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------