Re: Haskell 98 library: Directory.lhs

[S. Alexander Jacobson]

Although it is not relevant to H98, I would like to advocate that
either the name or the functionality of this module be changed.
interface akin to the Java Naming & Directory Inderface (JNDI).

JNDI defines an API that applications may use to access directories
(file, ldap, nds, rmi, corba, etc).   Service providers must implement the
API it whatever manner makes sense for the application.  It also includes
semantics for references (e.g. symlinks) and saving/getting objects from
the directory. The JNDI package comes with a file system service provider. 
(see http://www.javasoft.com/products/jndi/)

Functions for manipulating the files and file system directories are all
in java.io.File  (see 
http://www.javasoft.com/products/jdk/1.2/docs/api/java/io/File.html)
In addition to methods like canRead() and canWrite, the File object has a
method isDirectory() which returns Boolean and a method list() which
returns the directory contents if the file is also a directory.

Java also has seperate stream classes which are somewhat anaglogous to
the Haskell handles in the IO module.

In contrast, the haskell IO library seems to be a hodgepodge of stream and
file based semantics and the allocation of some of those semantics to
Directory.lhs seems sort of arbitrary.

In addition it does not appear to take advantage of opportunities for
genericity...why not allow people who write file manipulation code to
reuse that code for other objects that have semantics similar to files and
filesystems.

As a whole, Haskell's Directory and IO modules feel a bit ad hoc.  Why
not copy semantics from something that is already in use (and allow
users to reuse file system functions for non implementation defined
objects?

In other words, why not copy the file signature from java and make it
abstract so that users can implement file system like objects themselves
as well.

> class File a where  --copied from java
>   constructFile::String->a
>   canRead::a->IO Boolean
>   canWrite::a->IO Boolean,
>   create::a->IO -- creates file in filesystem
>   delete::a->IO, -- deletes file from filesystem
>   exists::a->IO Boolean, --does file exist in filesystem?
>   list::a->[File a]
> ...etc        
                
> data SystemFile = ...implementation dependent
> instance File SystemFile where
>  ....

Similarly, the IO module could benefit from making Handles less
implementation dependent.  For example, one might want to reuse buffering
code in a network application, but the existing IO module presumes that
buffering is only an issue in file applications.
I would expect an inteface more like

> class Reader a where -- copied fromhaskell
>  read::a->IO Char
>  readString::a->Integer->IO String -- could have default
>  readAll::a->IO String --could have default
>  ready::a->IO Boolean

> data SystemFileReader = ....implementation dependent
> instance Reader SystemFileReader where

The virtue of this implementation is that is allows users to
write different readers for different application domains.
For example, the buffering strategy for local files might be different
than that for network files which might be different from input from a
socket.

-Alex-





On Wed, 10 Mar 1999, Simon Peyton-Jones wrote:

> Folks,                A Haskell 98 addendum
> 
> Lennart points out that in a fit of enthusiasm I made the
> Permissions data type abstract, adding functions for
> 
>   readable, writable, executable, searchable :: Permissions -> Bool
> 
> What I totally failed to notice is that you then
> can't *set* the permissions to anything, because there's no
> way of constructing a value of type Permissions.
> 
> Well, the bits are frozen, but I propose to regard this as a gross
> "typo" and add it to the typos page.  But what's the fix?  One
> possibility would be to keep Permissions abstract, and 
> add more functions, but I think a better thing to do is simply
> to revert the change, and make Permissions concrete as it was
> before:
> 
> data Permissions =    Permissions {
>       readable, writable, executable, searchable :: Bool
>       }
>       deriving ( Eq, Ord, Read, Show )
> 
> So the "typo" fix I propose is
> 
>       - eliminate the separate functions readable, writable,
>               searchable, executable
> 
>       - make Permissions concrete as above (that of course
>               adds readable etc back in as field names)
> 
> Any objections?  I don't want to look foolish a second time!
> 
> Simon
> 

___________________________________________________________________
S. Alexander Jacobson                   Shop.Com
1-212-697-0184 voice                    The Easiest Way To Shop