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:
<
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.
<
> 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
Hello aldirithms, Saturday, August 5, 2006, 5:11:19 PM, you wrote:
<
>
you can see it in that way: something which has no parameters and return different values on different calls is not a function in _mathematical_ meaning of this word. Haskell functions is a mathematical (it also named "pure") functions. In order to deal with such real-world issues I/O functions just have additional hidden argument which is considered as containing "state of the world" at the moment of function call. this allow us to think that we "getstr" is really a pure (mathematical) function, just called with different parameters each time (because state of the world is definitely changed between calls :D ) you can read further explanations at the http://haskell.org/haskellwiki/IO_inside
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 C, function reading string form keyboard can be defined as char *getstr(); as you can see, it don't have string arguments in Haskell, such function will be defined as getstr :: IO String which is internally translated to something like getstr :: WorldState -> String and compiler silently adds different "world state" values to each call, making them different in mathematical sense -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
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:
<
participants (4)
-
aldirithms@gmx.net -
Bulat Ziganshin -
Johan Grönqvist -
luc.duponcheel@accenture.com