On 13 Sep 2005, at 14:45, Dhaemon wrote:

Hello, I'm quite interested in haskell, but there is something I don't understand(intuitively). I've been crawling the web for an answer, but nothing talks to me... So I was hoping I could find some help here: "How is evaluating an expression different from performing action?" I'm puzzled... Doesn't it amount to the same thing? Maybe I have a wrong definition of "evaluating"(determine the value of an expression)? Examples would be appreciated. Also, just for kicks, may I had this: I read the code of some haskell-made programs and was astonished. Yes! It was clean and all, but there were "do"s everywhere... Why use a function language if you use it as an imperative one?(i.e. most of the apps in http:// haskell.org/practice.html)

The difference is all about referential transparency -- in short, a function given the same inputs will always give the same result. This is not the same as in imperative languages, where functions/ methods/actions can have 'side-effects' that change the behavior of the rest of the program. Take this example: C program: #define square(x) ((x) * (x)) #define inc(x) ((x)++) int myFunc (int *x) { return square(inc(*x)); } the C preprocessor will re-write the return line to: return ((((x)++)) * (((x)++))); this will be performed in sequence, so, x will be incremented (changing the value of x), and that result will be multiplied by x incremented again. so if we run myFunc(&y), where y is 5, what we get is 5 incremented to 6, and them multiplied by 6 incremented to 7. So the result of the function is 42 (when you might reasonably expect 36), and y is incremented by 2, when you might reasonably expect it to be incremented by 1. Haskell program: square x = x * x inc = (+1) myFunc = square . inc and we now call myFunc 5, we get this evaluation: myFunc 5 is reduced to (square . inc) 5 (square . inc) 5 is reduced to square (inc 5) square (inc 5) is reduced to square ((+1) 5) square ((+1) 5) is reduced to square 6 square 6 is reduced to 6 * 6 6 * 6 is reduced to 36 If you want to study these reductions on a few more examples, you might want to download the Hat tracer, and use hat-anim to display reductions step by step. Bob

On Tue, Sep 13, 2005 at 01:45:52PM +0000, Dhaemon wrote:

Also, just for kicks, may I had this: I read the code of some haskell-made programs and was astonished. Yes! It was clean and all, but there were "do"s everywhere... Why use a function language if you use it as an imperative one?(i.e. most of the apps in http://haskell.org/practice.html)

Monadic code isn't synonymous with imperative code, and "do" only indicates that you're looking at monadic code. The Maybe monad is an example of a very useful, very non-imperative monad that can be used to cleanly write functional code. On the other hand, IO is always monadic, so perhaps you're looking at IO code. But I'd assert that even monadic IO code isn't quite the same as true "imperative" code. I'd probably say that the difference has to do with whether you create modifiable "variables". When you start doing that, whether you're in the ST monad or the IO monad, I think you're writing imperative-style code. But I think that that sort of usage is actually pretty uncommon. -- David Roundy

Am Dienstag, 13. September 2005 15:45 schrieb Dhaemon:

[...]

Also, just for kicks, may I had this: I read the code of some haskell-made programs and was astonished. Yes! It was clean and all, but there were "do"s everywhere... Why use a function language if you use it as an imperative one?(i.e. most of the apps in http://haskell.org/practice.html)

Note that do expressions are not expressions whose evaluation has side-effects. The evaluation of a do expression doesn't yield the result of the action it describes, causing side-effects, but it yields the action itself. Evaluation of this action is done seperately.

Thanks in advance,

Best wishes, Wolfgang

On 13/09/05, Dhaemon wrote:

Hello, I'm quite interested in haskell, but there is something I don't understand(intuitively). I've been crawling the web for an answer, but nothing talks to me... So I was hoping I could find some help here: "How is evaluating an expression different from performing action?" I'm puzzled... Doesn't it amount to the same thing? Maybe I have a wrong definition of "evaluating"(determine the value of an expression)? Examples would be appreciated. Also, just for kicks, may I had this: I read the code of some haskell-made programs and was astonished. Yes! It was clean and all, but there were "do"s everywhere... Why use a function language if you use it as an imperative one?(i.e. most of the apps in http://haskell.org/practice.html)

Thanks in advance

It should be made clear that the only IO action which is ever actually performed in a Haskell program is main (short of loading the code up in an interactive environment and getting it to run other actions separately). IO actions themselves are described in a pure functional, referentially transparent way. Evaluation of an expression is different from performing an IO action in the various things which can occur as a result. Essentially the only thing which should be able to occur (without some major cheating) as the result of evaluating a Haskell expression, is the production of a value, and this value will always be the same for a given expression. It should not print things to the screen, fire packets over the network, read from the random number generator or read or write to files. (There are instances where IO is lazily delayed until a result is demanded, so that evaluation of what looks like a pure list results in reading from a file, but one can only construct these situations so that they occur inside the execution of an IO action anyway. The lists aren't really pure.) The upshot of this is that if one has a Haskell expression, within time and memory constraints, one can evaluate it on any computer, under any ordinary circumstances, and get the same result. One can't make that claim about performing an IO action. IO actions when performed may read from the keyboard or network or filesystem (as well as write to the screen, etc.). However, evaluation of an expression which represents an IO action always yields the same action (even if that action may not do the same thing when it is actually performed in the end). That's the distinction that's being made. As it has been pointed out in other posts, do notation is pure, in the sense that do blocks are expressions which evaluate to the same thing every time. This thing may be an IO action, but it may also be a list, a Maybe value, a binary tree, a function of type s -> (a, s) (called a state computation), a graph, or any number of other monadic types. Most monads m are not "one-way" in that one can extract results from the monadic containers - there usually exist functions (m a -> a) -- IO is a major example of a case where this doesn't hold, but it's by far not the only example of a monad. - Cale