On Sun, 4 Jul 2004 19:17:53 +0100, Alastair Reid <[EMAIL PROTECTED]> 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
_______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
