[MLton-user] Feature request: MLton.Finalizable

[Vesa Karvonen]

On Mon, Jun 2, 2008 at 5:29 PM, John Reppy <jhreppy at mac.com> wrote:
> I'm using finalization as a backstop for explicit management
> of resources (e.g., textures and shaders).

Is this for the sml3d library/project (at
http://smlnj-gforge.cs.uchicago.edu/projects/sml3d/)?

At any rate, is there some reason why checkout on that project has (at
some point) been restricted to developers?  (I know it was previously
open for public checkout as I tried some of the examples.)  I've
recently been thinking about doing a little 3D graphics programming in
SML.  I wrote a very simple stripifying algorithm (for static
geometry) last week and now I've been looking at how to best interface
with Open GL vertex buffer objects in SML.  (From about 1997 to 2002 I
worked at Housemarque (http://www.housemarque.com), which is an
independent games developer.)  If nothing else, I would be interested
in looking at the library and might have some feedback.

> I could streamline this
> process with the addition of the following two operations to
> the Finalizable structure:
>
>      (* remove all finalization functions from the object *)
>        val cancelFinalizers : 'a t -> unit
>      (* change the state of the finalized object *)
>        val update ('a t * 'a) -> unit
>
> The implementation is straightforward:
>
>        fun cancelFinalizers (T{finalizers, ...}) = finalizers := []
>        fun update (T{value, ...}, x) = value := x
>
> Any chance of getting these added to MLton?

These seem reasonable and useful to me, but I can't immediately say
whether the above implementations might have some subtle semantic
oddities.  For example, would it be possible that when update is given
the only reference to the finalizable object, finalizers might
actually be run before the assignment takes place.  So, for example,
the following code

  fun delete resource =
     (withValue (resource, fn SOME r => reallyDelete r)
    ; update (resource, NONE))

would be incorrect and could cause reallyDelete to be called twice for
the same resource (once in delete and again in the finalizer).

-Vesa Karvonen