On Thu, Apr 9, 2009 at 11:46 PM, Brandon S. Allbery KF8NH
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