Re: [Haskell-cafe] Process properties as global values
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. An ironic historical footnote here: Back in the ancient days, only hbc provided access to command line arguments and environment variables, and it did so through a global. The argument on this subject happened back then, too (in the early days of the Haskell mailing list!). I have no idea if there are archives from back then... -Jan-Willem Maessen ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Process properties as global values
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 [EMAIL PROTECTED] http://www.volker-wysk.de ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Process properties as global values
On Sun, 4 Jul 2004, Georg Martius wrote: 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. 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 [EMAIL PROTECTED] http://www.volker-wysk.de ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Process properties as global values
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. -- Alastair Reid ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Process properties as global values
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
Re: [Haskell-cafe] Process properties as global values
Alastair Reid writes: 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. To reinforce that point: Command-line arguments and environment variables are specific to a certain type of platform. There have been popular consumer operating systems (the classic Mac OS, to name one) that have no analogous features. Keeping the implementation-specific features locked in the IO monad may not be the ideal solution, but it's better than having them scattered throughout the program. -- David Menendez [EMAIL PROTECTED] http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Process properties as global values
Sorry, but why does [making process properties global values] not break the purity? If i call a function, that depends on global parameters twice within different environments it behaves different. The argument goes that purity is concerned with what happens in a single run of the program and any single run sees just one environment. This might make some tasks easier, but testing becomes harder. That doesn't affect whether it is pure or impure. In any case, it doesn't make testing that much harder. After all, every program that reads a file also produces different behaviour (making testing harder) in different environments. The point of my message wasn't really about purity because, in this case, I think purity is a red herring. It's true that a lot of Haskell's desirable properties stem from purity but it's not true that just because something is pure, it is a good idea to add it to the language. -- Alastair Reid ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
