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.
>
> Unless, of course, you consider StateOfUniverse to encapsulate all past,
> present, and future events (a 4-dimensional value). In which case, you
> don't need to return a new StateOfUniverse, since it will be exactly the
> same as the one given, except maybe with different `currentTime' value.
> But I'm getting way too deep here.
>
> 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.
>
> 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.
This is another reason I'm sceptical about referential transparency in
any functional system of IO (streams, monads, continuations, world as value..)
It is hard to sensibly define interaction between a timeless universe
of pure functions and values and a real universe which continually evolves
in real time. A state transformer method is about as good as you'll
get, but this requires that somehow the times of future events is
information which is embedded in the whatever state the program last left
the universe in. Perhaps some people believe this, but I don't think
the world works this way. (And even if this were true, unless we had
some systematic way of extracting this information and predicting the
future, it won't help us at all.)
Regards
--
Adrian Hey
