main::[String]->IO() ?
Hello everybody, each time I write an application that makes use of command line arguments I have to copy&paste the code for dealing with these args to my program from a reference implementation, because it is so hard to remember. What do you think about changing the default type of main or providing an alternative, e.g., main_args, just like in C or Java? I think this would simplify everyday-programming a lot. Or are there any severe theoretical (semantical) problems (main is running in the IO monad either way)? Ciao, Steffen
I typically do: ... main = getArgs >>= go go [whatever] = ... On Mon, 22 Mar 2004, Steffen Mazanek wrote:
Hello everybody,
each time I write an application that makes use of command line arguments I have to copy&paste the code for dealing with these args to my program from a reference implementation, because it is so hard to remember. What do you think about changing the default type of main or providing an alternative, e.g., main_args, just like in C or Java?
I think this would simplify everyday-programming a lot. Or are there any severe theoretical (semantical) problems (main is running in the IO monad either way)?
Ciao, Steffen _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
-- Hal Daume III | hdaume@isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume
Steffen Mazanek <s_mazanek@gmx.de> writes:
Hello everybody,
each time I write an application that makes use of command line arguments I have to copy&paste the code for dealing with these args to my program from a reference implementation, because it is so hard to remember. What do you think about changing the default type of main or providing an alternative, e.g., main_args, just like in C or Java?
I think this would simplify everyday-programming a lot. Or are there any severe theoretical (semantical) problems (main is running in the IO monad either way)?
Ciao, Steffen
main_args :: [String] -> IO () main_args args = do foo args bar args versus main :: IO () main = do args <- getArgs foo args bar args Frankly, I don't think there's a compelling reason to change main's type or introduce a new entry point. Not that I don't think that accepting a [String] is slightly more elegant. Have you considered one of the more sophisticated high-level argument libraries? Hugs & kisses, Mikael Brockman
--- Steffen Mazanek <s_mazanek@gmx.de> wrote:
I think this would simplify everyday-programming a lot. Or are there any severe theoretical (semantical) problems (main is running in the IO monad either way)?
The type signature of main currently is: main :: IO() and the new type signature would be main :: [String] -> IO() Since type signature declarations for functions are generally considered good practice, those who use "<- getArgs" would actually need to type two extra characters. And those who do not use getArgs typically (which may or may not be the case in general), would type an extra 14 characters. One might also consider getProgName and getEnv to be plausible arguments to main as they are for some variants of c. However, in this case we are getting quite excessive with main's arguments. Aside from the two points made above, the current, no-argument version of main would support new programming models elegantly. Future systems development may lead to better system-program communication. GUI's, for instance, might have a special configuration line of communication for window placement which could be vastly superior to parsing a list of strings. Although there aren't any theoretical problems with main having an argument, I think that current practicioners would find it more efficient the way it is now. David J. Sankel
David Sankel <camio@yahoo.com> writes:
Since type signature declarations for functions are generally considered good practice, those who use "<- getArgs" would actually need to type two extra characters. And those who do not use getArgs typically (which may or may not be the case in general), would type an extra 14 characters.
Well, that is to ignore the possibility that if 'main' has arguments, you can pattern-match directly on them, rather than using a more verbose 'case' expression as is currently widely practiced after 'getArgs'. However, as has already been mentioned, there is nothing to stop the original poster defining a library wrapper such as withArgs :: ([String]->IO ()) -> IO () withArgs = (>>=) getArgs and then the "boilerplate" is simply main = withArgs main' main' [] = ... main' (x:xs) = ...
One might also consider getProgName and getEnv to be plausible arguments to main as they are for some variants of c. However, in this case we are getting quite excessive with main's arguments.
Again, some simple wrappers will do the job nicely. withProgArgsEnv :: (String -> [String] -> [(String,String)] -> IO ()) -> IO () withProgArgsEnv main = do p <- getProgName a <- getArgs e <- getEnvironment -- not standard main p a e Maybe a small set of such wrappers could be added to the hierarchical libraries, if someone wants to do a little design. Regards, Malcolm
Hello, thank you for all the valuable comments. A main function with arguments would correspond better to the principle of the least surprise, however, you are perfectly right with your arguments, too. getArgs is not so hard to remember I guess :-) Bye, Steffen
Hello again.
Since type signature declarations for functions are generally considered good practice, those who use "<- getArgs" would actually need to type two extra characters. And those who do not use getArgs typically (which may or may not be the case in general), would type an extra 14 characters.
One might also consider getProgName and getEnv to be plausible arguments to main as they are for some variants of c. However, in this case we are getting quite excessive with main's arguments.
Just a thought: is there a Haskell extensions that allows some kind of optional function arguments? Not that I want to compare Haskell and C :-) but as far as I know in C you have the choice. I could imagine that it may be possible with Template Haskell. Furthermore I see some analogies with "Formatting: a class act" by Ralf Hinze (as far as I understand this (and this is not so deep) value dependent types are simulated by type classes). Bye, Steffen
participants (5)
-
David Sankel -
Hal Daume III -
Malcolm Wallace -
Mikael Brockman -
Steffen Mazanek