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

[C. McCann]

Oops, forgot to send this to the list... sorry, Sjoerd.

On Thu, Nov 11, 2010 at 11:54 AM, Sjoerd Visscher <sjoerd at w3future.com> wrote:
>> You would lose many uses of equational reasoning in your programs. Have you
>> every substituted 'x * 2' for the expression 'x + x' in one of your programs,
>> or vice versa? You can no longer do that, because someone may be serializing
>> the function you're writing, checking how it's implemented, and relying it.
>
> Yes, but it would not break any existing code. It would only break code that knowingly did the wrong thing.

Or code that unknowingly depends transitively on code that does the
wrong thing. In that regard it would be much like unsafePerformIO, and
about as trustworthy. Better off just having any such "serialize" be
safely in IO, and let people who want to live dangerously just use
unsafePerformIO to get around 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?

I'd venture that perhaps because seq only behaves differently when one
possible outcome is _|_. An unsafe serialize could distinguish between
two non-bottom values, which means the sketchy behavior could be free
to wreak havoc in code that's not crashing.

For instance, assuming serialize can be applied to functions of any
type, it would probably be trivial to write a function (isExpr :: a ->
Bool) that reports whether an arbitrary term is a primitive value or
the result of some expression, which then lets you write a function
with type (forall a. a -> a) that is NOT equivalent to id, which could
then be passed freely into any other piece of code you like. That
sounds like buckets of fun, doesn't it?

- C.