On Sun, 4 Jul 2004 19:17:53 +0100, Alastair Reid wrote:

...

I'm just wondering, why haven't process properties (such as the command line arguments, or the parent process id), which are inherently global, been made global values in the Haskell standard? You could avoid needlessly carrying around these values, you wouldn't need to lift some functions into the IO monad...

Why do you need to lift function into IO monad? You just let you give the parameters in the main, which is IO () anyway, and then you can pass the ordinary values to the functions that depend on them.

This is true and you don't break purity and common programming tasks become a bit easier because you need less plumbing. One argument against doing so is that it will make data dependencies less obvious.

Sorry, but why does it not break the purity? If i call a function, that depends on global parameters twice within different environments it behaves different. This might make some tasks easier, but testing becomes harder.

At the moment, if you want to know where your data goes, you can usually follow a path from where it is read from a file (or whatever) through to where it is passed to a function which uses it. I've found this very useful in the past and wish it applied to my current project (a joint project with a very good C programmer and written in C).

I don't know if this is a conclusive argument but it's certainly true that making process properties global would make it harder to find what code depends on the command line, environment, etc. and understanding a program _might_ become harder. I agree with you.

Georg

-- Alastair Reid

On Sun, 4 Jul 2004, Georg Martius wrote:

On Sun, 4 Jul 2004 19:17:53 +0100, Alastair Reid wrote:

...

...

I'm just wondering, why haven't process properties (such as the command line arguments, or the parent process id), which are inherently global, been made global values in the Haskell standard? You could avoid needlessly carrying around these values, you wouldn't need to lift some functions into the IO monad...

Why do you need to lift function into IO monad? You just let you give the parameters in the main, which is IO () anyway, and then you can pass the ordinary values to the functions that depend on them.

Er, I meant, you need an IO action to get the value, thus a function needs to be monadic to get that value. Of course you can also pass it as an argument instead. Cheers, V.W. -- Volker Wysk http://www.volker-wysk.de

On Sun, 4 Jul 2004, Alastair Reid wrote:

...

I'm just wondering, why haven't process properties (such as the command line arguments, or the parent process id), which are inherently global, been made global values in the Haskell standard? You could avoid needlessly carrying around these values, you wouldn't need to lift some functions into the IO monad...

This is true and you don't break purity and common programming tasks become a bit easier because you need less plumbing. One argument against doing so is that it will make data dependencies less obvious.

At the moment, if you want to know where your data goes, you can usually follow a path from where it is read from a file (or whatever) through to where it is passed to a function which uses it. I've found this very useful in the past and wish it applied to my current project (a joint project with a very good C programmer and written in C).

I don't know if this is a conclusive argument but it's certainly true that making process properties global would make it harder to find what code depends on the command line, environment, etc. and understanding a program _might_ become harder.

You have a point. Functions will get implicit input values, much like global variables in imperative languages. They won't be self-contained any longer. Of course functions refer other functions/values, but these are true constants (meaning values). Global values like command line arguments are constant only for the given run of the program. However, I have a bunch of shell scripts written in Haskell (using HsUnix), with actions depending on some command line arguments all the time. It's cumbersome to carry them around all the time. On the other hand, it's not such a big deal either... I'll try it out, making these arguments global values, using unsafePerformIO. It must be assessed whether the greater simplicity outweights the obfuscation added by the "implicit arguments". Cheers, V.W. -- Volker Wysk http://www.volker-wysk.de