[Haskell-cafe] Re: To yi or not to yi, is this really the
question? A plea for a cooperative, ubiquitous, distributed integrated
Tom.Schrijvers at cs.kuleuven.be
Thu Jun 21 03:59:42 EDT 2007
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
> 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?
> 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
>>> 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.
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
Department of Computer Science
tel: +32 16 327544
e-mail: tom.schrijvers at cs.kuleuven.be
More information about the Haskell-Cafe