[Haskell] Re: Why is getArgs in the IO monad?

[Conal Elliott]

Oh!  I hope that Haskell language and library semantics are defined
independently from any particular Haskell implementation.

     - Conal

-----Original Message-----
From: br276 at hermes.cam.ac.uk [mailto:br276 at hermes.cam.ac.uk] On Behalf
Of Ben Rudiak-Gould
Sent: Tuesday, January 18, 2005 8:13 AM
To: Conal Elliott
Cc: 'Jim Apple'; haskell at haskell.org
Subject: Re: [Haskell] Re: Why is getArgs in the IO monad?

Conal Elliott wrote:

 >The meaning of
 >"length getArgs" would then have to be a value whose type is the
meaning
 >of Haskell's "Int", i.e. either bottom or a 32-bit integer.  I'm
 >guessing that none of those 2^32+1 values is what you'd mean by
"length
 >getArgs".  On the other hand, the IO monad is a much roomier type.

I'm not strongly convinced by this argument. I don't think you can tell 
me which particular Char value you mean by the expression (maxBound :: 
Char) either, yet you probably wouldn't argue for changing maxBound's 
type. I think Jim's claim is that there's no clear dividing line between

these cases, and I tend to agree. Even if you want to disallow explicit 
recompilation (and how do you define "compilation" denotationally?), an 
automatic rollout of a new version of Hugs could lead to successive 
invocations of a script using different values of (maxBound :: Char) 
(or, more plausibly, some constant defined in the library) without user 
intervention. How is this different from any other environmental change,

such as a change in the program arguments? I think this is what Jim 
meant when he wrote

 >It seems that, looking out at the world from main, the args passed to
 >main and the compilation happen at the same time (before, long long
 >ago). What motivation would we have for treating them differently?

-- Ben