I'd like to ask a question concerning a following passage in "Yet another Haskell Tutorial" that ushers in the topic of monads:

I, as a beginner here, believe the haskell cafe list is the correct place for beginner questions.

<<After all, suppose you have a function that reads a string from the keyboard. Ifyou call this function twice, and the user types something the first time and something else the second time, then you no longer have a function, since it would return two different values.>>

How do I have to interpret this? I cannot make sense of it for I do not see where the definition of a function that I know is violated. I view it that way: The string is just a kind of argument to the string-reading function and that different strings (i.e. different arguments) yield different return values is a commonplace phenomenon with functions, isn't it? How do I have to alter this (over?)simple interpretation to see the point the author wants to make?

In this case I think you mean that the string typed on the keyboard is a "kind of" argument to the function. I think this is the problem. A function call f x to a function f should always return the same value if x is the same, and reading from keyboard and stating that the string read is a "kind of extra argument" to the function is not allowed. I think what is called functions here would be called "pure functions" ina different language. This would mean a function that only depends on its arguments. Using this definition a zero-parameter function (like the readLine function mentioned above) must always return the same value. This property is violated. This requirement makes Haskell a purely functional language. / johan

Hi, The very idea of 'pure functional programming' is that it is 'declarative' (i.e. works with constants (nothing ever changes)). As a consequence, given a function 'f' and an input 'x', evaluating the expression 'f x' should always behave in the same way. Input/Output is an example of a programming aspect that is not pure in the sense above. The idea of I/O is (for example) to change information on your file system. So, a function that appends the string "Foo" to a file 'Foo' and then shows the contents of 'Foo', will NOT always behave in the same way. If the contents of the file was originally "someString", then, the first time the function is invoked, it will show "someStringFoo", and the second time the function is invoked, it will show "someStringFooFoo". One of the goals of monads is to encapsulate non-pure aspects (side effects) behind a convenient interface. Luc -----Original Message----- From: hugs-users-bounces@haskell.org on behalf of aldirithms@gmx.net Sent: Sat 8/5/2006 3:11 PM To: Hugs-Users@haskell.org Subject: [Hugs-users] Excerpt from "Yet another Haskell Tutorial" Hello, (and sorry for the preceding accidental empty message), I'd like to ask a question concerning a following passage in "Yet another Haskell Tutorial" that ushers in the topic of monads: <<After all, suppose you have a function that reads a string from the keyboard. Ifyou call this function twice, and the user types something the first time and something else the second time, then you no longer have a function, since it would return two different values.>> How do I have to interpret this? I cannot make sense of it for I do not see where the definition of a function that I know is violated. I view it that way: The string is just a kind of argument to the string-reading function and that different strings (i.e. different arguments) yield different return values is a commonplace phenomenon with functions, isn't it? How do I have to alter this (over?)simple interpretation to see the point the author wants to make? Thank you very much in advance. Christian -- Echte DSL-Flatrate dauerhaft für 0,- Euro*. Nur noch kurze Zeit! "Feel free" mit GMX DSL: http://www.gmx.net/de/go/dsl _______________________________________________ Hugs-Users mailing list Hugs-Users@haskell.org http://www.haskell.org/mailman/listinfo/hugs-users This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.