serialization and globalization

[Stephen Weeks]

> No, that doesn't help.
> Consider the code
> 	val stuff: ref int = []
> 	val f (x: int): unit = stuff := x::( ! stuff)
> where these are all global.  I think of f as being `add something to the global
> list stuff.  If I serialize f with no globalization, when I de-serialize it
> I will get a new procedure f' which pushes something on to the stuff' list
> (which will start with what ever value it had when f was serialized).  It will
> do nothing to stuff.  In this example, it will be a memory-leaking no-op, even
> if there is other code which references stuff (unless I serialize some object
> which is closed over that other code at the same time).  This semantics is
> well defined (i.e., does NOT depend on how clever the optimizer is) but isn't
> very useful.

OK, I guess I had only thought about the cases where I had been bitten 
several times already: a mutable object was globalized and hence I was 
not closed over it, even though I wanted to be.  What you are pointing 
out is that the opposite situation is just as problematic.  

However, I still don't see any other reasonable semantics other than
the one I proposed (i.e. no globalization of mutable objects).

> You can hack around this kind of stuff with handles in Kali, but it isn't very
> nice.  (Handles are essentially global (across all address spaces) variables
> which are not copied.)

I think it would be pretty easy to add a little bit of compiler
support in order to implement a new kind of ref cell that doesn't
get serialized, although I'm not quite sure this is the same thing as
handles.  I guess there are two properties of handles:
  * non-serializability
  * global uniqueness
Are there others?

Could somebody write me a signature?

signature HANDLE =
   sig
      type 'a t

      ...
   end

> A nicer solution is what Cardelli's Oblique does: for mutable objects he
> basically sends a toady which knows, when it is mutated, to really send the
> mutation back to where the cell lives.

Another possible interpretation of your example is that you want a
different version of stuff in each address space, and you want f to
use whatever version for the address space it is in.

I would also like to point out that the only case I am thinking of is
different than the ones that y'all keep mentioning.  In my example,
there is only one program running, and it saves some state to a file.
While this might be viewed one instance of the program as sending a
message (via the filesystem) to its future self, it doesn't make sense 
to think of sending any messages back from the future instance to the
current instance.