Felipe Lessa felipe.lessa at gmail.com
Tue Aug 10 17:53:46 EDT 2010

```On Tue, Aug 10, 2010 at 6:36 PM, Martijn van Steenbergen
<martijn at van.steenbergen.nl> wrote:
> 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 '<-'.
>

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.
```