Michael Hobbs <[EMAIL PROTECTED]> writes:
> Adrian Hey wrote:
> >
> > On Mon 24 Jan, Michael Hobbs wrote:
> > > (*) One place where the World -> (World, a) model breaks down is when
> > > the IO function is a blocking function such as "getChar :: IO Char". If
> > > this function was equivalent to World -> (World, a) then that would mean
> > > that the result is completely determined by the input World value.
> >
> > As a world value sceptic myself, I am reluctant to say this, but in
> > all honesty I don't think that this argument holds. If I understand
> > you correctly your objection is that getChar should never block, it
> > should get a character instantly because the information about which
> > character will eventually be got should already be embedded in the
> > input world value.
>
> Actually, I never thought about whether or not getChar should ever
> block. My intention is to point out that trying to wed referential
> transparency with I/O using the concept of World values is filled with
> philosophical ambushes and tiger traps. The particular trap I was trying
> to point out here was that of determinism. You just pointed out a
> different one along the same lines: If getChar really was referentially
> transparent, with respect to the given World value, should it block?
This doesn't seem to be a problem to me. The second time around the
world is different. Consequently the code is executed. Haskell has
no sense of time, so whether it blocks or not is unimportant to the
language. But the passage of time can be mixed in with the change
of state in the world, if need be.
Minerva uses world state passing too, btw.
Cheers,
Julian.
