[ANN] Directory 1.0 released

[Martin Wierich]

Hi all,

"Zuurbier, E. - AMSXE" wrote:

>
> I found out that the some functions use and return the environment variable
> ...
>
> pd_StringToPath :: !String !*env -> (!(!Bool, Path), !*env) | FileSystem env
> pathToPD_String ::      !Path !*env -> (!String,  !*env)        | FileSystem
> env
>
> ...where it seems that the only purpose of the environment variable is to
> retrieve the platform-id. Would not it be easier if the platform-id were put
> in the deltaSystem-module as a constant (in the IOInterface folder)? That
> would free users from chaining the environment-variable through these two
> functions.

I thought about that:

:: PlatformId = UnixPlatform | WindowsPlatform | MacPlatform

pd_StringToPath :: !PlatformId !String -> (!Bool, !Path)
pathToPD_String :: !PlatformId !Path   -> String
getPlatformId   :: !*env -> (PlatformId, !*env) | FileSystem env (or whatever)

Advantage: As you said, the user doesn't have to chain the environment-variable
through these two functions. Adding a function call that needs such an
environment (World or IOSt or whatever) somewhere in your program where you
don't have such an environment can be burdensome (_really_ burdensmone).

Disadvantage: It becomes "to easy" to write code that turns out to be platform
dependent. If you use such a PlatformId without retrieving it from the *World
then you have a platform dependent program, e.g. writing

  # (x, world) = getDirectoryContents (pd_StringToPath WindowsPlatform
"dir1\\dir2") world

This would cause problems under Unix and MacOS

Here one can argue again a lot, for instance "why should writing platform
dependent programs made be harder than it could". Finally I decided _not_ to
offer this PlatformId type. I think that in most cases you will use these two
conversion functions in conjunction with the other functions from the Directory
module. And there you have the desired environment available.

cheers
  Martin Wierich
  University of Nijmegen