[MLton-user] Feature request: MLton.Finalizable

[John Reppy]

On Jun 2, 2008, at 12:29 PM, Vesa Karvonen wrote:

> 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/)?

Yes.

>
>
> 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.

When we upgraded the version of gforge that we use, the way that  
anonymous
access was handled changed, which is probably why you can no longer  
access
it.  There is an awful lot of partially finished stuff, which is why  
I've
held off announcing it, but I've enabled anonymous access if you want to
take a look at the source.  Note that it requires the latest version  
of MLton
from svn to compile.

>
>
>> 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).

I don't think that this is a problem because the implementation of  
finalizable
objects creates a weak pointer to "value" to track the reachability of  
the
finalized object, but one could also change update to

	fun update (f as {value, ...}, x) = (value := x; touch f)

	- John