Clarify how functions interact with directoryness about fpath

[dbuenzli]

@dsheets I'd be interested in your opinion on this.

Currently the function Fpath.parent (spec, examples) always returns paths without directoryness.

This behaviour matches the implementation of POSIX dirname --- in fact if I read well the specification it says nothing about this, but in the examples provided on that page and on my system (osx), all paths returned by dirname except / do not have directoryness.

Given the semantics of Fpath.parent do you think I should rather always return paths with directoryness or . and let the client remove the trailing slash if it whishes so using Fpath.dir_to_file ?

[dsheets]

Yes, I think that is the right direction. As the parent of a path must always be a directory, I think explicitly and consistently typing this is the right semantic. I would go so far as to suggest that parent("..") = "../../" and parent("foo/") = "./". I think dirname is a bad interface as it is not consistent and understands nothing of relative path semantics.

This would give you the invariant that every path returned from parent will end in "/". One possible catch with this design is the inability to concatenate an absolute path after the parent path but I believe that this is a feature as relative path concatenation will always work as it should. A final thing to consider is the change of referent when the parent path is a symlink. In the directoryness case, the parent paths will never be symlinks as any sane implementation will treat a trailing "/" as forcing resolution. In the other case, the dereference of a parent path could yield a symlink in the non-. and non-/ cases. I believe the advice here should be to always use dir_to_file to generate "node" paths to interrogate for symlink-nature.

I hope this helps.

[dbuenzli]

Thanks for your input.

I would go so far as to suggest that parent("..") = "../../" and parent("foo/") = "./"

I guess you would then also have parent "." = "../".

One possible catch with this design is the inability to concatenate an absolute path after the parent path but I believe that this is a feature as relative path concatenation will always work as it should.

I don't understand this, concatenating an absolute path to another one seems like is a non-sensical operation in all cases (or in fpath, following the design of other libraries simply returns the the absolute one) and I don't understand why you mention this in the context of parent.

In the other case, the dereference of a parent path could yield a symlink in the non-. and non-/ cases.

What do you mean by the other case ? You mean in the current behaviour that doesn't force the final /

[dsheets]

I don't understand this, concatenating an absolute path to another one seems like is a non-sensical operation in all cases (or in fpath, following the design of other libraries simply returns the the absolute one) and I don't understand why you mention this in the context of parent.

This is relevant to parent as fpath may be used in contexts interchangeable with shell scripting. It is common in shell scripting to do things like $PATH/continuing/the/path which is a concatenation of an absolute path and, yes, is nonsensical. It is syntactically convenient, though, as it abuses the lexer of the script to terminate the variable identifier before /. Consider $(dirname $PATH)/more/path. I think that the typed, sane algebraic construction of OCaml and fpath make this a non-issue.

What do you mean by the other case ? You mean in the current behaviour that doesn't force the final /

Yes, sorry. I mean in the dirname case which is similar to the present behavior.

[dbuenzli]

So I wanted to provide a function split_parent : t -> t * t with split_parent p = (par,b) where par is a directory path that contains p and b an absolute path such that Fpath.append par b represents the same path as p, directoryness included (but not necessarily syntactically). The idea was then that parent was simply fst split_parent.

This poses two problems:

1. When p is a root path. This can easily be solved by having par being p itself and b be ./. For example for the root path "/" we then get ("/", "./") which appended is "/./" which is equivalent to "/". par does contain p under the view that root paths do contain themselves and b is a relative path. So this seems correct according to the semantics given above.
2. Dot and dot dot only paths. This one seems unfixable. For example with "./", the natural parent would be "../" however we then can't have a value for b without consulting the file system. Same for "../". Once you go up with .. segments there's no way back.

So maybe split_parent should be called split_dir and the left hand side should simply be guaranteed to be a directory (rather than the stronger property of being a parent directory). Case 2. would then simply yield the pairs (p, "./") like for roots. And the parent function should be defined separately, handling .. segments as David suggested above.

[dbuenzli]

Current master has the final design which can be reviewed here. All functions operating on paths now preserve or indicate directoryness of their results.