[Haskell-cafe] Re: To yi or not to yi, is this really the question? A plea for a cooperative, ubiquitous, distributed integrated development system.

[apfelmus]

Tom Schrijvers wrote:
> On Thu, 21 Jun 2007, Pasqualino 'Titto' Assini wrote:
>> 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.

I don't agree, I think that serialize in the IO-monad is perfectly fine
and a good idea :) I mean, a "similar" implementation would be

  serialize :: (Int -> Int) -> IO String
  serialize f = randomIO

which isn't a treat to equational reasoning as well.

Of course, serialize can only live due to his brother

  compile :: String -> Maybe (Int -> Int)

with the property

  fmap compile . serialize = return . Just


That being said, serialization of function values is a practical
problem. GHC's internal representation changes often and it would be
very tedious to keep serialization working. But Clean can serialize
function values.

Regards,
apfelmus