[Haskell-cafe] Re: [Haskell] Top Level <-

[John Meacham]

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⑈