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
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
[email protected]
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: [EMAIL PROTECTED]
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
