[Haskell-cafe] Re: Referential Transparency and Monads

Gregg Reynolds dev at mobileink.com
Fri Apr 10 09:52:01 EDT 2009


On Thu, Apr 9, 2009 at 11:46 PM, Brandon S. Allbery KF8NH
<allbery at ece.cmu.edu> wrote:
>
> I still don't understand this; we are passing a World and getting a World
> back, *conceptually* the returned World is modified by putStr.  It's not in
> reality, but we get the same effects if we write to a buffer and observe
> that buffer with a debugger --- state threading constrains the program to
> the rules that must be followed for ordered I/O, which is what matters.
>

You might find it useful to back up and think about the nature of
computation.  I did, anyway, when I was slogging through this stuff.
Computability is all based on intuition about the *process* of
calculating (see section 9 I think it is of Turing's original paper).
IO "operations" - whatever one calls them - are by definition not
computable.  "Referentially transparent IO expressions" is an
oxymoron, since the operations involved do not (cannot) correspond to
any process that corresponds intuitively to computation and thus
cannot refer transparently.  So (going back to your original question)
we can never get RT, but we can get the next best thing, which is
manageability, which is what monads and other IO techniques are all
about.

YMMV, but for me the IO-as-state-transformer-operating-on-World is
quite misleading.  It's one possible method for dealing with IO
conceptually but it's easy to get the incorrect impression that IO
*is* some kind of state transformation, when in fact there is no
essential connection between the two.  There is no "state" nor
"transformation" involved; an IO expression just references the result
of some indeterminate non-computing process, just like a referentially
transparent expression like '3+2' references the result of a
determinate computing process.  Monads etc. just allow us to use IO
expressions as if they were computable even though they're not, by
enforcing sequencing.  Or to put it another way, what really counts is
predictability, not referential transparency.

-gregg


More information about the Haskell-Cafe mailing list