[Haskell-cafe] Re: Haskell serialisation, was: To yi or not to yi...

Tom Schrijvers Tom.Schrijvers at cs.kuleuven.be
Thu Jun 21 08:11:13 EDT 2007

On Thu, 21 Jun 2007, Pasqualino 'Titto' Assini wrote:

> Hi Tom,
> On Thursday 21 June 2007 08:59:42 Tom Schrijvers wrote:
>> On Thu, 21 Jun 2007, Pasqualino 'Titto' Assini wrote:
>>> Thanks for the explanation.
>>> But, doesn't this simply mean that the correct signature would be:
>>> serialize :: (Int -> Int) -> IO String
>>> to take in account the fact that serialise really use  'external'
>>> information that is not in the domain of pure Haskell functions?
>> I'm afraid not. The beauty of the IO monad is that it permits
>> equational reasoning over I/O operations. E.g. because of the definition
>>  	print = putStrLn . show
>> the compiler can freely inline calls to print. Although there's I/O
>> involved, equational reasoning is still valid: the inlined call will
>> behave in the same way as the original code. Hence, the compiler does not
>> have to be aware of IO and treat it in a different way.
>> Your serialize function does not have that property. You don't want its
>> argument to be inlined or otherwise replaced with an equivalent
>> expression.
> Is it so?
> I understand that, depending on what the compiler does the result of :
> do
>    let  f = (*) 2
>    print $ serialise f
> might differ as, for example, the compiler might have rewritten f as \n ->
> n+n.
> But, why would that make equational reasoning on serialise not valid?
> Isn't that true for all functions in the IO monad that, even when invoked with
> the same arguments, they can produce different results?

Not if you take the ``state of the world" to be part of the arguments. If 
two programs behave differently for the same arguments and the same state 
of the world, then they're not equivalent. You do want your compiler to 
preserve equivalence, don't you?


Tom Schrijvers

Department of Computer Science
K.U. Leuven
Celestijnenlaan 200A
B-3001 Heverlee

tel: +32 16 327544
e-mail: tom.schrijvers at cs.kuleuven.be

More information about the Haskell-Cafe mailing list