[MLton-devel] Re: finalization in MLton

[Stephen Weeks]

> The good news is that I think I've figured out how to solve all
> pressing problem.  So now all what is left is A Simple Matter Of
> Programming.

Great.  It'd be nice if this could be done in time for our next MLton
public release, which is currently planned for late June.

> > I just checked in an attempt at implementing finalization in MLton.
> 
> Arg.  This is the only thing I have found time to implement.  I've
> attached my attempt together with a test example.
...
> I'm happy to see that our interfaces looks a lot like each other.
> That must mean that we agree on the basic ideas.

Yes.  The implementations are somewhat similar, although I used
closures to hide the type of the value while you used exceptions.  One
problem I see with your withValue implementation is that it doesn't
ensure the finalizer runs after the function completes.  That is
essential -- imagine if the finalizable value were a pointer to a C
structure that were freed by the finalizer before the function could
complete.

> The example works with mlton-20030419 but if I try to use yesterdays
> CVS mlton, then MLton spews tons of SSA SML at me and ends with:
>       unhandled exception: TypeError

I've checked in a fix for that bug.

> But yesterdays CVS mlton works better for me on one of my other
> programs.  Where mlton-20030419 ends the compilation with:
>       shrinker raised Prim.apply raised assertion failure: SmallIntInf.fromWord
...
> 
> It is by no means a minimal example, but you can find a snapshot of
> the code here:
>         http://www.it.edu/people/kfl/tmp/omega.tgz

Hmmm.  I compiled and ran this with 20030419 without problems.

omega% ls
IntMap.sig  OmegaInt-mlton.sml	omega-mlton.cm	Omega.sml     RBIntmap.sml
IntMap.sml  OmegaInt.sig	Omega.sig	RBIntmap.sig  testing-mlton.sml
omega% mlton
MLton 20030419 (built Sat Apr 19 10:37:44 2003 on redhat71)
omega% mlton omega-mlton.cm 
omega% omega-mlton
x0 = ~19
x1 = 0
x2 = 0
x3 = 29
x4 = ~30
x5 = ~10
x6 = 22

So, you must either be using an SML/NJ-compiled version or modified
sources.  In any case, I do see how the error might have happened and
have checked in a fix.  I would like to check my guess though, so
could you please send more details on the configuration of MLton with
which you generated the error.

> Getting back to the mGTK port.  I have a hack-and-slash implementation
> of the Callback interface I talked about last time:
> 
> signature Callback =
> sig
>     eqtype id
>     
> (*  val register     : 'a -> id
> *)
>     val register     : (int -> int) -> id
>     val unregister   : id -> unit
>     val isRegistered : id -> bool
> end
> 
> If you want it I can send you my implementation together with test
> program.

Sure, we can take a look.  The MLton.FFI structure is under active
development as we speak.

> I can see that I won't have a lot of time the next two weeks to work
> on the port.  Because I'll spend almost all my time on porting an
> other SML/C library to MLton.  And for this other library I need
> finalization as well :-)

Excellent.  You can alpha test our new stuff. :-)


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