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

[C. McCann]

On Fri, Nov 12, 2010 at 4:24 AM, Ketil Malde <ketil at malde.org> wrote:
> IMO, it's morally different, you're now operating on a file, and you
> shouldn't rely on the contents being predictable.  You can make the
> sin-bin argument that IO can do anything, but I think there's a moral
> distinction between
>
>  serialize :: a -> IO ByteString
>  x <- serialize f
>
> and
>
>  serialize :: a -> Opaque
>  store :: Opaque -> FilePath -> IO ()

Any distinction here is mostly at the level of API design and informal
semantics; I'm inclined to agree with your preference, but as far as
impacts on the formal semantics of pure code go, these are essentially
equivalent.

> You could probably already snarf chunks of the heap and dump them to file.

Yep, and this is pretty much the reason, taken to its logical
conclusion, why almost all bets are off about what IO computations can
potentially do.

>> I suppose one could object that this isn't actually serializing
>> anything at all; to which I would respond that, in pure code, how do
>> you expect to tell the difference?
>
> Nice one :-)
>
> I guess the real question is what are the useful, pure operations on an
> opaque type that can contain arbitrary functions.

I would be very surprised if there were any that couldn't just as well
be done on the function directly. Even extracting type information
could be problematic if done incorrectly! Consider a function
(inspectType :: Opaque -> Serialization.Type), where the Show instance
for Type produces an approximation of the type signature the function
was declared with. Reasonable? Nope, we just broke everything. Imagine
a function taking an argument of type ((a, a) -> a). If by serializing
the argument it can recover the declared type signature it could
distinguish between fst and ((\(x, _) -> x) :: forall a. (a, a) -> a),
which again opens the door to non-parametric behavior. On the other
hand, (inspectType :: Opaque -> Data.Typeable.TypeRep) would probably
be safe, because it supports only monomorphic types.

- C.