On Tue, Aug 10, 2010 at 6:36 PM, Martijn van Steenbergen
On 8/10/10 23:27, Felipe Lessa wrote:
If we had in C:
return (randomNumber(10, 15) + randomNumber(10, 15))
That would not be the same as:
int x = randomNumber(10, 15) return (x + x)
That's not fair. You're comparing C's '=' with Haskell's '='. But you should be comparing C's '=' with Haskell's '<-'.
In your Haskell example, x :: IO Int. In your C example, x :: Int.
Well, then maybe we will agree with eachother when we decide on what is "fair". =) You quoted: Given the definition of a Haskell function, Haskell is a pure language. The notion of a function in other languages is not: int randomNumber(); The result of this function is an integer. You can't replace the function call by its result without changing the meaning of the program. So, given the functions int randomNumber(int, int) randomNumber :: Int -> Int -> IO Int what is "replace the function call by its result"? Function call in C is, for example, randomNumber(10, 15); and the result of this call has type "int". In Haskell, what is a function call? Well, it's randomNumber 10 15 and the result is "IO Int". When we "replace the function call by its result", I think it is fair to replace the C function call by an "int" and the Haskell function call by an "IO Int", because that is what those functions return. To fit your definition of fairness I would have to say that function application is \cont -> randomNumber 10 15 >>= \x -> cont x which has type "(Int -> IO a) -> IO a". I don't think this is function call at all, and only works for monads. IMHO, Ertugrul was pointing out the difference of C's int and Haskell's IO Int. An 'IO Int' may be passed around and you don't change the meaning of anything. Cheers, =) -- Felipe.