>> [Mind you, persistent *closures*? That's got to be a fairly rarely 
>> used feature...]
> 
> Yah.  That they even mention it boggles my mind.

5th rule of software design: If it's technically possible to use your 
product in a certain way, somebody will try to actually use it that way.

You *know* this to be true! ;-)

>> The I/O monad is unusual as monads go, but essentially the I/O 
>> functions return I/O command objects instead of actually *performing* 
>> I/O, 
> 
> Yeah, that I figured out. I'm just trying to wrap my head around how 
> that would work with (say) the clock, or the status of whether your ISP 
> is currently screwy, or something like that, just in terms of 
> "referential transparency".
> 
> I'm trying to figure out conceptually how you represent "the clock" for 
> example in a way that it's "referentially transparent".  Or can you not 
> actually do that, and that's the point of a monad?

I'm going to go with "you can't - hence the monad".

The "get time" function just returns an I/O command object. You can 
replace that function call with the command object it returns and the 
meaning of the program is left completely unchanged. Thus it is 
referentially transparent.

The Haskell runtime actually *gets* the clock time, and it does this 
theoretically "after" the Haskell code has already been run and 
generated its giant command object, so...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message