tag:blogger.com,1999:blog-8648268364549955959.post4011498768315324311..comments2024-03-29T11:05:55.471+00:00Comments on the literate programmer: Unthreadingctfordhttp://www.blogger.com/profile/05464902188219000642noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-8648268364549955959.post-58937741447014668732012-06-10T13:17:41.889+01:002012-06-10T13:17:41.889+01:00I mean a value is basically a function that takes ...I mean a value is basically a function that takes no arguments. In Lisp, they're syntactically distinct because you need () for function invocation, but in Haskell there's really no difference. So I meant that an immutable value is indistinguishable from a function that takes no arguments and always returns the same answer.<br /><br />It's a good point about the I/O monad. My understanding of Haskell I/O is that it models I/O as a function from one state of the world to another, and that the world is threaded through I/O actions by the monad.<br /><br />In the end, Haskell I/O functions are referentially transparent because they don't do I/O - they just describe it. The non-referentially transparent stuff is delegated to the evaluation environment that invokes the main function.ctfordhttps://www.blogger.com/profile/05464902188219000642noreply@blogger.comtag:blogger.com,1999:blog-8648268364549955959.post-66135412100726192282012-06-10T12:22:41.216+01:002012-06-10T12:22:41.216+01:00Good point. Reading input isn't (normally) con...Good point. Reading input isn't (normally) considered mutability, though it is referentially non-transparent and does force the reader to consider time.<br /><br />There's definitely a deep relationship between the two concepts. Perhaps you could consider immutability to be a special case of referential transparency for constant functions?ctfordhttps://www.blogger.com/profile/05464902188219000642noreply@blogger.com