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