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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
