2009/6/22 Colin Paul Adams :

...

...

...

...

...

"Judah" == Judah Jacobson writes:

   Judah> On Sun, Jun 21, 2009 at 11:12 PM, Colin Paul    Judah> Adams wrote:    >> I've been hoogling like bad to try to determine if a function    >> like this exists.    >>    >> getDirectoryContents returns sub-directories as well as file    >> names. I want only the latter, so I'm looking for a suitable    >> filter.

   Judah> Use System.Directory.doesDirectoryExist/doesFileExist.

Thanks.

it seems it's time i went to the optician again.

I'm not surprised that anyone would make the mistake. I think that the two functions should be named "isDirectory" and "isFile", but it seems that "isDirectory" was already taken by another function in System.Directory, which is quite unfortunate. "does" goes against the intuition one gets from pretty much everything else in Haskell, where "is" seems to be the convention. In fact, Hoogle only knows about three functions which start with "does". -- Deniz Dogan

2009/6/22 Duncan Coutts :

On Mon, 2009-06-22 at 08:53 +0200, Deniz Dogan wrote:

...

2009/6/22 Colin Paul Adams :

...

...

...

...

>> "Judah" == Judah Jacobson writes:

   Judah> On Sun, Jun 21, 2009 at 11:12 PM, Colin Paul    Judah> Adams wrote:    >> I've been hoogling like bad to try to determine if a function    >> like this exists.    >>    >> getDirectoryContents returns sub-directories as well as file    >> names. I want only the latter, so I'm looking for a suitable    >> filter.

   Judah> Use System.Directory.doesDirectoryExist/doesFileExist.

Thanks.

it seems it's time i went to the optician again.

I'm not surprised that anyone would make the mistake. I think that the two functions should be named "isDirectory" and "isFile", but it seems that "isDirectory" was already taken by another function in System.Directory, which is quite unfortunate. "does" goes against the intuition one gets from pretty much everything else in Haskell, where "is" seems to be the convention. In fact, Hoogle only knows about three functions which start with "does".

One explanation is that isBlah asks "is this thing a blah", but we're not asking that because there is an indirection via the filepath. We're asking "does this filepath refer to a directory" not "is this filename a directory". The latter could be a function:

isDirectory :: FileInfo -> Bool

along with a hypothetical

getFileInfo :: FilePath -> IO FileInfo

Duncan

I think see what you mean, but I find the argument more of an excuse to the poor naming than a solid argument for it. Following the convention and intuition that most users have should be more important than making the (sometimes unnecessary) distinction between a directory and the path to it. -- Deniz Dogan

2009/6/22 Max Rabkin :

On Mon, Jun 22, 2009 at 2:09 PM, Deniz Dogan wrote:

...

I think see what you mean, but I find the argument more of an excuse to the poor naming than a solid argument for it. Following the convention and intuition that most users have should be more important than making the (sometimes unnecessary) distinction between a directory and the path to it.

I disagree. (isDirectory "/no/such/directory/") should equal true: the given FilePath is a directory path (on Unix), since it ends with a slash. However (doesDirectoryExist "/no/such/directory") should return false, since there is no such directory.

Are you saying that when a function is named "isDirectory" you expect it to only check for a trailing forward slash character? -- Deniz Dogan

Deniz Dogan writes:

...

One explanation is that isBlah asks "is this thing a blah", but we're not asking that because there is an indirection via the filepath. We're asking "does this filepath refer to a directory" not "is this filename a directory".

I think see what you mean, but I find the argument more of an excuse to the poor naming than a solid argument for it. Following the convention and intuition that most users have should be more important than making the (sometimes unnecessary) distinction between a directory and the path to it.

It is more important to be consistent and logical than to follow conventions and intuitions. And at any rate, convention is that 'isFoo' is a pure function with the type 'FooType -> Bool', clearly different from 'doesDirectoryExist', which returns an IO action. So IMO 'isDirectory "/foo/bar/"' should always return false, since it is a string, not a directory. -k -- If I haven't seen further, it is by standing in the footprints of giants

On Tue, 2009-06-23 at 09:31 -0400, Brandon S. Allbery KF8NH wrote:

On Jun 22, 2009, at 07:37 , Duncan Coutts wrote:

...

One explanation is that isBlah asks "is this thing a blah", but we're not asking that because there is an indirection via the filepath. We're asking "does this filepath refer to a directory" not "is this filename a directory". The latter could be a function:

isDirectory :: FileInfo -> Bool

along with a hypothetical

getFileInfo :: FilePath -> IO FileInfo

Hypothetical?

...

import System.Posix.Files (getFileStatus, isDirectory)

Yeah, if we could make a standard portable variant of this, that'd be great. Duncan

On Jun 23, 2009, at 10:34 , Duncan Coutts wrote:

On Tue, 2009-06-23 at 09:31 -0400, Brandon S. Allbery KF8NH wrote:

...

Hypothetical?

...

import System.Posix.Files (getFileStatus, isDirectory)

Yeah, if we could make a standard portable variant of this, that'd be great.

I've wanted to do that ever since I tripped over it implementing the original filetests in pugs; I know it can be done with some genericness but don't know enough win32 to do it. One question is what to do with the non-generic stuff. For example, Win32 doesn't have symbolic links, but does have reparse points which are sort of similar if you squint; they're a superset of symlink functionality. (The closest thing Unix (not POSIX) has is mountpoints, but those are userspace aside from . and .. being the same inode. POSIX doesn't touch this space, IIRC, because there are POSIX implementations for Win32 (no mountpoints, some implementations may use reparse points to simulate them) and OpenVMS (no mountpoints).) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH