Can I suggest that this thread, interesting as it is, might usefully migrate to haskell-café. (Apart from anything else, there's another similar thread running there, and it makes sense to keep together.) Posting a summary back to the Haskell list, in due course, would be great. Simon | -----Original Message----- | From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Benjamin | Franksen | Sent: 23 November 2004 13:21 | To: haskell@haskell.org | Subject: Re: [Haskell] Re: Top Level TWI's again was Re: Re: Parameterized Show | | On Tuesday 23 November 2004 00:10, Aaron Denney wrote: | > On 2004-11-22, Benjamin Franksen <benjamin.franksen@bessy.de> wrote: | > > On Monday 22 November 2004 09:38, Adrian Hey wrote: | > >> You have yet to | > >> explain how you propose to deal with stdout etc.. | > > | > > I see absolutely no reason why stdxxx must or should be top-level mutable | > > objects. They can and should be treated in the same way as environment | > > and command line arguments, i.e. | > > | > > getArgs :: IO [String] | > > getEnv :: String -> IO String | > > getStdin, getStdout, getStderr :: IO Handle | > > | > > Note that (just like environment and command line arguments) these | > > handles may refer to completely different things on different program | > > runs. | > | > Er, no. The handles can be considered as the same but _pointing_ to | > different things on different runs. | | I wrote "may refer to", not "are", so yes. | | > Keeping them outside the IO monad, | > and only accessing them inside -- i.e. the current situation -- would be | > fine. | | I beg to differ. Note, I do not claim they are unsafe. | | > They're not mutable in any sense. | | Well, a variable in C is not mutable in exactly the same sense: It always | refers (="points") to the same piece of memory, whatever value was written to | it. Where does that lead us? | | Ben | -- | Top level things with identity are evil. -- Lennart Augustsson | _______________________________________________ | Haskell mailing list | Haskell@haskell.org | http://www.haskell.org/mailman/listinfo/haskell