[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
slash).
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
directory-ness?)
> > 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
all....
Andrew
More information about the Haskell-Cafe
mailing list