On Thu, Aug 28, 2008 at 09:00:41AM +0100, Lennart Augustsson wrote: > I'm certain you can write a kernel in Haskell where the only use of > global variables is those that hardware interfacing forces you to use.
And hence you need a safe way to use program-scope variables. It is true that there are many many programs that can be written without them. But those don't concern us, if there are _any_ programs that need them that we wish to write in haskell then we need a safe way in haskell to use them. The truth is, 'process scope' is a useful scope to attach information too. Many operating systems attach various resources to process scope, memory allocation, file descriptors, protection domains. this in and of itself makes it useful for any programs on these operating systems to be able to augment this process scope. I mean, why is it okay to use 'process scope' state provided by the operating system or haskell runtime, but _not_ be able to express such things in haskell itself? I mean, lets look at the items provided for by plain haskell 98 which involve entities that are process scope or bigger: getStdGen, setStdGen, getEnv, getArgs, stdin,stdout,stderr, cpuTimePrecision, isEOF, getCurrentDirectory, setCurrentDirectory, system, exitWith, exitFailure, getProgName, getClockTime, probably others in more subtle ways. do we really want to say that these are all wrong or _must_ be provided by C or the operating system because implementing them in haskell would somehow be unclean? Why shouldn't we be able to implement the concept of a 'current directory' in haskell when we are perfectly happy to use the OS provided one? What if you have an exokernel, where it is expected these things _will_ be implemented in the userspace code. why shouldn't that part of the exokernel be written in haskell? John -- John Meacham - ⑆repetae.net⑆john⑈ _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe