implementation of file-related modules

Isaac Jones ijones at syntaxpolice.org
Thu Oct 9 00:18:15 EDT 2003


Greetings,

I've been looking over some of the file-related modules such as
System.Directory and System.Posix.{Directory,Files}, and I have some
questions.

* Excuse my ignorance of Windows, but I'm assuming that the
  System.Posix module does not exist on Windows?  Is windows the only
  system where this is the case?

* I've noticed that System.Directory.renameFile behaves differently
  between ghci, nhc, and hugs.  In particular, ghc is the only one who
  complains when it's a directory.  Is there anything evil about using
  renameFile to rename a directory?  It would be nice if they all
  acted the same, particularly since renameDirectory is conveniently
  located in the same module.

* Speaking of which, in System.Posix, the Directory and File
  operations are broken up into separate modules.  It is a little odd
  to have file related functions in System.Directory.  Should they be
  moved?

* Some languages have a means of building paths in a portable way.  It
  would be nice if we had access a file separator (like "/" in unix
  and "\" in windows).  These would probably belong in the
  System.Directory module?  Java (for instance) allows access to these
  things through the java.lang.system.getProprerty function.  That
  function takes a string and returns a string:

    "path.separator" Path separator (for example, ":")
    "file.separator" File separator (for example, "/")
    "user.home"      User home directory
    "user.name"	     User account name

    // might come in useful:
    "os.arch"    Operating system architecture
    "os.name"    Operating system name
    "os.version" Operating system version

  Now using getProperty for this makes sense in Java, but for Haskell,
  I would expect to have functions for these.  I'm not sure where all
  of them would go.  Is there any roadblock to implementing something
  like this?

* Another item that would be useful in the System.Directory class
  would be some kind of config file path.  On Debian, that would be
  "/etc", on some systems, it might tend to be more often
  "/usr/local/etc".  (I'm not sure if there's a good way to abstract
  the difference between a user config file and a system config file.
  User config files tend to be in ~/ and start with a dot whereas
  system config files end up in /etc, and don't start with a dot.)

These last few points are rather related in that they are both
dependent on particular operating systems, and a means of abstracting
away system-specific details in order to write more portable code.
Are any of these good ideas?


peace,

isaac


More information about the Libraries mailing list