That precedent supports the view that e.g. a command-line flag shouldn't affect behavior without the type reflecting it, e.g. by doing IO, but the de facto use of the unsafe IO trick means not everyone agrees.

For those interested, here's [1] a case where treating command line arguments as top level constants went wrong. Look specifically at the section named "Crime Doesn't Pay". Best, Facundo [1] http://www.aosabook.org/en/ghc.html

Date: Tue, 3 Jul 2012 17:49:48 -0400 From: Alvaro Gutierrez Subject: Re: [Haskell-cafe] Martin Odersky on "What's wrong with Monads" To: Dominique Devriese Cc: haskell-cafe@haskell.org Message-ID: Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jun 28, 2012 at 2:53 PM, Dominique Devriese wrote:

...

2012/6/27 Tillmann Rendel :

...

How would you implement this requirement in Haskell without changing the line "amount (Leaf x) = x"?

I may be missing the point here, but having worked on large code bases with a wide variety contributors before, I find it very advantageous that programmers are prevented from writing an amount function whose behaviour depends on command line arguments without at least an indication in the type. The fact that the function can not perform stuff like that is precisely the guarantee that the Haskell type gives me...

I don't think there's an answer that's uniformly right; it depends on whether you think of the input to the program, e.g. the environment, command-line arguments, etc. as 'constant' and in some sense, pure. The latter are constant in the sense that they never change, but they are not fixed at compile-time. Other languages effectively treat them as pure (by passing them directly to main), whereas Haskell chooses not to, which is probably the reason why getArgs has IO in its type (something that seems unintuitive at first.)

That precedent supports the view that e.g. a command-line flag shouldn't affect behavior without the type reflecting it, e.g. by doing IO, but the de facto use of the unsafe IO trick means not everyone agrees.