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