RE: Yet Another Monad Tutorial

Thanks. Quite comprehensive. Peter Van Roy (the Mozart/Oz guy) said this on the PragProg list, and I didn't have the knowledge to respond. It's a point you might want to address, perhaps in this section?: http://www.nomaware.com/monads/html/laws.html#nowayout I can't decide for myself if he's right or not. It seems to me that monadic IO functions aren't pure, but that doesn't mean that *all* monadic functions are impure, does it? Or could you argue that monadic IO functions are pure: it's just that their input includes the outside world, which means that you can never invoke an IO function more than once with the same arguments? -----------------------------------------------------------------------
Care to explain why you think Haskell is not pure?
Purely functional = you are always defining and calling pure functions. Calling a pure function with the same arguments always gives the same results. In Haskell, if monadic state is used, then this is not true (there is support from the syntax + type system to hide the state argument). So Haskell's monadic state is an implementation of state *on top of* a purely functional language. Saying that Haskell is 'purely functional' is reasonable if you want to present it to non-functional programmers. But the reality is not that simple. It's perhaps better to say that Haskell allows a clear separation of the purely functional core from the rest, which is a Good Thing. It's like saying that Erlang is a functional language. It's true that Erlang has a functional core. But the concurrent message passing built on top is very important and definitely not functional! Peter
-----Original Message----- From: Jeff Newbern [mailto:jnewbern@yahoo.com] Sent: 12 August 2003 10:41 To: haskell-cafe@haskell.org Subject: Yet Another Monad Tutorial
Hello everyone,
Due to the scarcity of monad tutorials available (:^), I have written one of my own. I hope that this one is both more gentle and more comprehensive than many of the other tutorials out on the 'net, and I am looking for feedback from experienced Haskellers and novices alike.
You can find the tutorial at
http://www.nomaware.com/monads/html/
The tutorial begins from first principles and introduces the monad concept, details the implementation and usage of all of the standard monads in Haskell and the monad template library and explains the use of monad transformers. The tutorial contains 23 individual sections and 18 files of example code illustrating different monad concepts.
I hope that this tutorial is useful to many people, and I would love to hear your experiences and suggestions for improving it.
Thanks, Jeff Newbern jnewbern@yahoo.com
***************************************************************** The information in this email and in any attachments is confidential and intended solely for the attention and use of the named addressee(s). This information may be subject to legal professional or other privilege or may otherwise be protected by work product immunity or other legal rules. It must not be disclosed to any person without our authority. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. *****************************************************************

On Tuesday, 2003-08-12, 12:14, CEST, Alistair Bayley wrote:
[...]
Care to explain why you think Haskell is not pure?
Purely functional = you are always defining and calling pure functions. Calling a pure function with the same arguments always gives the same results. In Haskell, if monadic state is used, then this is not true (there is support from the syntax + type system to hide the state argument). So Haskell's monadic state is an implementation of state *on top of* a purely functional language.
Hello, I wouldn't agree. In my opinion, in Haskell a function always gives the same result when called with the same arguments, even if it involves I/O. So Haskell is truely purely functional. The point is that evaluating an expression of an IO type doesn't actually do the I/O and yield the result of the I/O action. It yields a result which *describes the action* to do. The I/O is only finally done because the meaning of a Haskell program is to execute the action described by main. For example, the function readFile is pure. For a specific string s the expression readFile s always yields the same result: an I/O action which searches for a file named s, reads its content and takes this content as the result of the *action* (not the expression). Correct me if I'm wrong. I wouldn't say that I'm an expert in these things.
[...]
Wolfgang
participants (2)
-
Bayley, Alistair
-
Wolfgang Jeltsch