RE: Yet Another Monad Tutorial

From: Wolfgang Jeltsch [mailto:wolfgang@jeltsch.net]
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).
What about getChar? This is a function which takes no arguments, yet returns a (potentially) different value each time. I know, I know: it returns an IO action which reads a single char from the terminal and returns it. Is the IO monad the only one (currently) in which you would say that it "returns an action", which is then executed by the runtime system? I would have thought that monads that are not involved in IO (e.g. State) would be pure in the sense that Van Roy was thinking. You wouldn't need to describe functions in them as "returning an action". ***************************************************************** 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, 13:10, Alistair Bayley wrote:
From: Wolfgang Jeltsch [mailto:wolfgang@jeltsch.net]
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).
What about getChar? This is a function which takes no arguments, yet returns a (potentially) different value each time. I know, I know: it returns an IO action which reads a single char from the terminal and returns it.
Actually, getChar is not a function at all but it *is* the action you describe. ;-)
Is the IO monad the only one (currently) in which you would say that it "returns an action", which is then executed by the runtime system? I would have thought that monads that are not involved in IO (e.g. State) would be pure in the sense that Van Roy was thinking. You wouldn't need to describe functions in them as "returning an action".
State is similar to I/O. For example, take the function gets :: (state -> val) -> State state val. gets doesn't return a value of type val the same way readFile doesn't return a string. Instead, gets returns some kind of "state-transforming action" of type State state val which is internally represented by a function. The difference to the IO type is that you can implement useful (pure) functions with a type like ... -> State state val -> ... -> result where result doesn't involve the State type. So you can "execute" a state transformer as part of an expression evaluation and without special support by the runtime system. State is pure in the sense that pure "execution" is possible. Wolfgang

I think the crucial distinction is to think about is the difference between calculating a value (such as a character) compared to calculating an action (such as a computation that reads a character) --- one is wholly in your programming language while the other interacts with something outside your language (the I/O system). Many years ago we were all told it was a *good thing* to separate calculating values from *doing* I/O. Of course, you weren't actually *doing* any I/O when you *wrote* your program --- you were *calculating* (working out, writing...) your program. For most actions/computations, the properties you usually want is that A followed by (B followed by C) is the same as (A followed by B) followed by C and a unit (as in multiplication) or zero (as in addition) action. I guess the usefulness of this is quite subtle --- the Romans had no notation for zero and look what happened to them (although we still use Roman numerals for decoration). How do you know you have structured your program so that the preceding properties hold ? You show that you're working in the appropriate Monad --- remember, maths is the QA of programming. I suspect that tutorials should at some point mention some definitions of monads, monoids et al --- since this is where the power (sorry, QA) comes from. Phil On Tue, 12 Aug 2003, Bayley, Alistair wrote:
Date: Tue, 12 Aug 2003 12:10:24 +0100 From: "Bayley, Alistair"
Subject: RE: Yet Another Monad Tutorial From: Wolfgang Jeltsch [mailto:wolfgang@jeltsch.net]
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).
What about getChar? This is a function which takes no arguments, yet returns a (potentially) different value each time. I know, I know: it returns an IO action which reads a single char from the terminal and returns it.
Is the IO monad the only one (currently) in which you would say that it "returns an action", which is then executed by the runtime system? I would have thought that monads that are not involved in IO (e.g. State) would be pure in the sense that Van Roy was thinking. You wouldn't need to describe functions in them as "returning an action".
***************************************************************** 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. *****************************************************************
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Phil Molyneux email molyneux@kingston.ac.uk tel work 020 8547 2000 x 5233 direct 020 8547 8233 home 020 8549 0045 Kingston Business School room 339 WWW http://www.kingston.ac.uk/~ku00597 Kingston University, Kingston Hill, Kingston upon Thames KT2 7LB, UK ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I suspect that tutorials should at some point mention some definitions of monads, monoids et al --- since this is where the power (sorry, QA) comes from.
I was reading an overview-for-non-specialists of category theory earlier today, and was surprised by the familiarity of much of it - based on the little Haskell I'd learned. What it didn't have, and what I'd still like to read, is an overview-for-non-specialists of monads and monoids, as this was one bit of the mathematical terminology used by Haskell that was rather opaque to me - I think of a monad as a) a sort of a self-contained something-or-other in Liebniz's philosophy, and b) a scary baddy in the "ABC Warriors" comic strip published by 2000AD (I'm not making this up...). Dominic
participants (4)
-
Bayley, Alistair
-
Dominic Fox
-
Phil Molyneux
-
Wolfgang Jeltsch