[Haskell-cafe] Re: To yi or not to yi, is this really the question? A plea for a cooperative, ubiquitous, distributed integrated development system.

[Tom Schrijvers]

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