[Haskell-cafe] Serialization of (a -> b) and IO a

[Dan Doel]

On Thursday 11 November 2010 11:54:56 am Sjoerd Visscher wrote:
> Yes, but it would not break any existing code. It would only break code
> that knowingly did the wrong thing.

Well, if we added a function that randomly scrambled GHC's heap memory, it 
wouldn't break any existing code, because none would use it. :)

> > We already have a weak case of this, since (\x -> undefined x) can be
> > distinguished from undefined using seq, but that can be hand-waved away
> > by not worrying about bottoms so much. That isn't going to work for
> > serialize.
> 
> Why not?

Because, there is an argument to be made in the seq case that no one really 
cares about the differences it introduces. I don't usually care how my code 
works on bottoms, except inasmuch as it determines various performance 
characteristics of the code*, or whether it works on infinite values. I try, 
generally speaking, to write total functions, and run them on well-defined 
inputs. So when I reason about the programs, it is this aspect that I care 
most about, not about what happens when I feed in undefineds.

There are even folks that have worked on making this perspective rigorous. 
See, Fast and Loose Reasoning is Morally Correct.

serialize is not at all the same in this regard. There is no class of 
functions that is immune to its inspection powers, presumably, because that's 
its whole point. But that also means that there is no class of functions for 
which we are justified in reasoning equationally using the standard 
extensional equality. The only way that would be justified is saying, 
"serialize doesn't exist."

> Then don't do that. Being able to serialize functions is just as dangerous
> as having unsafePerformIO. If you don't use it, you don't have problems.

And unsafePerformIO's very name suggests that you're breaking things when you 
use it. It comes with lots of caveats, and the Haskell community will 
generally heap scorn on you if you use it for trivialities (or even non-
trivialities). I don't understand why it would be desirable for a serialize 
function to be branded, "don't ever use this unless you're an expert who knows 
what he's doing."

unsafePerformIO is, for many uses, a concession to low-level compiler 
extensibility. You can implement a fair amount of stuff in a library using 
unsafePerformIO that would otherwise require some kind of compiler support. 
What is the analogous motivation for functions to be turned into pure strings 
containing their code?

Of course, if you want, "everything is unsafe, be careful," there are many, 
many languages out there that already do that. For instance, ML**, Lisp, C, 
Java, Python, .... But this is Haskell, and we try to do a little better than 
that.

-- Dan

[*] Which is irrelevant to the reasoning in question. In fact, if you follow 
Bird's methodology, you first write a naive, obviously correct program, and 
then you transform it into a more efficient version via transformations you've 
shown to preserve semantics. This approach doesn't work if there are no 
correctness-preserving transformations, though.

[**] In fact, Alice ML (I think that's the right one) already has very fancy 
serialization stuff. You can store and load and send entire modules over an 
internet connection, I believe.