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

[apfelmus]

Tom Schrijvers wrote:
>> On Thursday 21 June 2007, Tom Schrijvers wrote:
>>> That wouldn't make a difference. If, from the pure Haskell point of view
>>> we can't tell the difference between two expressions that denote the
>>> same function, then operations in the IO monad should not be able to do so
>>> either.

IO cannot be understood by denotational semantics ("=") alone anyway. I
mean, we obviously have

  randomIO = randomIO

but operationally ("~>"), we have a non-deterministic choice of transition

  randomIO ~> return 42
  randomIO ~> return 13


> John Cast wrote
>> This doesn't make any sense to me.  IO is a non-determinism monad
>> (among many other things).  That's already true --- randomIO is one example;
>> Control.Exception.evaluate is another (and is already dependent on the
>> particular compilation choices made).  I think of Haskell `values' as
>> sets of legal representations anyway --- why shouldn't serialize be free to
>> make a non-deterministic choice from among those sets, just like evaluate can
>> make a non-deterministic choice from the set of exceptions an expression can
>> throw?
> 
> Good point. I agree, if the specification is non-deterministic, this
> should be alright.

Yes, the only guarantee you can get is that "compile" can turn your
serialization back into the same function:

  fmap compile . serialize = return . Just

To illustrate the point, here's a serialize for integers:

  serialize :: Int -> IO String
  serialize n = do
      k <- randomRIO (1,n-1)
      return $ "(" ++show k ++ "+" ++ show (n-k) ++ ")"

that gives intentionally different representations.

Regards,
apfelmus