[Haskell-cafe] RE: ANN: System.FilePath 0.9

Andrew Pimlott andrew at pimlott.net
Sat Jul 29 20:35:30 EDT 2006

On Sat, Jul 29, 2006 at 02:59:06AM +0200, Udo Stenzel wrote:
> Andrew Pimlott wrote:
> > Second, "foo" is just as good a directory
> > as "foo/" to the system
> ...unless you have both (think Reiser4) or you want to create the file
> (I think, but I'm not sure).  However, what's the point in being
> ambiguous when we can be explicit?  Sometimes there is a difference,
> libraries and tools shouldn't gloss over that without consideration.

As I said, it's one of those line-drawing exercises.  But your points
are well taken, and maybe the trailing delimiter should be part of the
model.  (My criterion has been whether any filesystem operations require
the trailing delimiter.  It sounds like with reiser4fs they might.)

> > But if you wish to make the distinction,
> > at least provide an operation that lets me force a path to be treated
> > "file-wise" or "directory-wise".
> WTF?!  A path names either a directory or a file.  We might have some
> operations that accept file names instead of path names.  What's there
> to be treated?  Being explicit about the distinction makes any ambiguity
> go away.

I'm confused now.  All I meant is that if there are some operations (eg.
getFileName) that behave differently based on the trailing delimiter, I
want some way to force one or the other behavior (so that the behavior
of my program is independent of whether the user typed a trailing

But since you said you don't like getFileName in the first place
(neither do I), maybe we're only appearing to differ.  What operations
in your mind would depend interestingly on the trailing delimiter?  (Is
your model basically a list of path segments plus a boolean representing

> > Filesystems are ugly. :-)
> So are microprocessors.  We can still have a nice programming language,
> and we can also have a nice filesystem language.

To take that analogy, we shouldn't be writing in terms of filesystems at


More information about the Haskell-Cafe mailing list