[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 at quantentunnel.de
Thu Jun 21 05:49:57 EDT 2007
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
More information about the Haskell-Cafe