On 07-Oct-1999, Adrian Hey <[EMAIL PROTECTED]> wrote:
> On Thu 07 Oct, Michael Hobbs wrote:
> > Michael Hobbs wrote:
> > > > Consider this:
> > > > > type IO a = StateOfUniverse -> (a, StateOfUniverse)
> > > > > -- Not syntactically correct, but you know what I mean.
> > > >
> > > > So anything that is declared, say `IO Int', means that it is actually a
> > > > function that reads in the state of the universe, potentially modifies
> > > > it, and then returns an Int value along with the new state of the
> > > > universe. The interesting thing to note is that the state of the
> > > > universe never changes between calls that are strung together using the
> > > > `>>=' operator. That is, the StateOfUniverse that is returned by the
> > > > first monad is exactly same state that is fed into the second. Whether
> > > > or not you want to call this "referentially transparent", well I guess
> > > > that's up to your own philosophic bias.
> > >
> > > I rescind the statement that "the state of the universe never changes
> > > between calls that are strung together using the `>>=' operator". After
> > > further consideration, I believe that that's incorrect.
You can fix that by defining each primitive IO operation to
wait some unspecified amount of time (the amount of time being
determined by the StateOfUniverse argument passed) before
performing its action.
> > The problem is a function like `getChar' that is declared `IO Char'. If
> > the user has not typed a character when this monad is invoked, it will
> > sit and wait for the event. That is, the current StateOfUniverse that is
> > passed to getChar has absolutely nothing in it to indicate what
> > character will be returned, unless it also contains future events.
Fine, so let it contain future events, or at least sufficient information
to determine those future events. What's the problem?
> > However, if we define `getChar' like this, we might get around the nasty
> > issue of future events:
> > > getChar = do
> > > c <- peekKbdBuffer :: IO [Char] -- length of 0 or 1
> > > if null c then getChar else return head c
> > In this case, `getChar' will continue looping until StateOfUniverse
> > changes such that the keyboard buffer actually has a value in it. Of
> > course, this means that the StateOfUniverse must be able to alter itself
> > somehow between the function calls.
No, see above: each primitive IO operation, including `peekKbdBuffer',
waits some period of time. So the StateOfUniverse returned from each
primitive IO operation is not going to be the same as the one that
was passed, because the new state will include the side effects of
any concurrent processes or user input in that time.
--
Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
