
On Thu, 21 Jun 2007, Pasqualino 'Titto' Assini wrote:
Thanks for the explanation.
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. Tom
Having "serialize" in the IO monad would do no harm as usually one serialise precisely to output a value :-)
So, is it correct to conclude that there is no theoretical reason why Haskell cannot have a built-in reification/serialisation facility?
titto
On Wednesday 20 June 2007 17:05:04 apfelmus wrote:
Pasqualino 'Titto' Assini wrote:
Is there any fundamental reasons why Haskell functions/closures cannot be serialised?
I believe that this is precisely what the distributed version of GHC used to do.
Most languages, even Java, have a reflection capability to dynamically inspect an object. It is surprising that Haskell doesn't offer it.
Inspecting functions is not referentially transparent. In Haskell, function equality is extensional, i.e. two functions are equal when their results are equal on all arguments. Intensional equality would mean that functions are equal when they have the same representation. If you allow a function
serialize :: (Int -> Int) -> String
that can give different results on intensionally different functions, you may not expect equations like
f (*3) == f (\n -> n+n+n)
to hold anymore (because f might inspect its argument). Also, having "serialize" somehow check whether intensionally different arguments are extensionally the same and should have a unique serialization is no option because this problem is undecidable.
Regards, apfelmus
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Tom Schrijvers Department of Computer Science K.U. Leuven Celestijnenlaan 200A B-3001 Heverlee Belgium tel: +32 16 327544 e-mail: tom.schrijvers@cs.kuleuven.be