[MLton-devel] Re: finalization in MLton

[Matthew Fluet]

> So the behaviour would change if I change
>
>    structure Finalized :> Finalized =
>
> to
>
>    structure Finalized : Finalized =

That won't change any behavior.

> Yes, if we are talking about and arbitrary intelligent SML compiler
> with weak pointers.  But with the current MLton what do I need to
> do to protect my finalized values?

Use refs ;-)

Keeping more in line with your implementation, you need a touch that just
might (but really won't) be called with different exceptions.  I'd propose
the following:

    type 'a value = {value  : root,
		     getVal : root -> 'a,
		     touch  : root -> unit}

	fun value (x, destructor) =
	    let exception WRAP of 'a
		fun getVal(WRAP x) = x
		fun touch(WRAP x) = ()
		val root = WRAP x
	    in  roots := (new root, fn() => destructor x) :: !roots
	     ; {value = root, getVal = getVal, touch = touch}
	    end


        fun withValue f (v as {value, getVal, touch}) =
            wind (fn () => f(getVal value),
                  fn () => touch value)

Note that the touch function is really equivalent to:
  fun touch exn =
    case exn of
      WRAP _ => ()
    | _ => raise Match
and due to the extensibility of exceptions, is implemented like
  fun touch exn =
    case exn of
      WRAP (_, r) => if r = r'
                       then ()
                       else raise Match
    | _ => raise Match
where r and r' are unit refs, tracking each new WRAP exception.  Once
again, from our point of view, the Match exception can never be raised,
because a touch function is only ever called with the root with which it
was defined.

Again, an arbitrarily smart compiler could figure this out.  In
particular, the closure for touch (holding r') is always paired up with a
getVal and value -- and value = WRAP(?, r'); so, the r' in the closure of
touch is really redundant.  If the compiler came up with a better
representation for the closures of touch and getVal and the representation
of value, then they could all share the same unit ref, and the comparision
r = r' would become r = r which is manifestly true.  But, don't expect to
see any such optimization any time soon. ;-)



-------------------------------------------------------
This SF.net email is sponsored by: If flattening out C++ or Java
code to make your application fit in a relational database is painful, 
don't do it! Check out ObjectStore. Now part of Progress Software.
http://www.objectstore.net/sourceforge
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel