[MLton-devel] mGTK for MLton

[Ken Friis Larsen]

Hi Guys,

> We've had some time to consider your request for additional MLton
> features to support mGTK.

Thanks a lot. This is going to be fun!


> Callbacks
> 	We've added a very simple facility for this that we hope is
> 	sufficient. 
> Finalization
> 	We can add support for weak pointers without too much
> 	difficulty.  Hopefully that is enough.
> Allocation of SML aggregate values from C
> 	We don't think this is necessary, and don't have plans to
> 	support it.  We have many examples of how to work around this
> 	missing feature in our implementation of the basis library.

OK, it looks like the port will be slightly more work than I had hoped
for on our side, ;-)  But definitely doable.


> Either way, please let us know and we can continue discussion to try
> to achieve the port.

I'll start the port of mini-mgtk as soon as possible.  Now the big
question is how and when can I get my hands on all the new goodies?
Should I start to track MLton CVS or could you sent us a quick mail
when there is a suitable snapshot?


> And please keep us up to date on the port's progress.

Will do.


> Here's the details.

> >    * Callback (ie., call a SML function from C).
>
> To address this need, we've added to MLton the ability to call a
> single SML function from C.  On the SML side, we export the function
>   
>   	val MLton.FFI.handleCallFromC: (unit -> unit) -> unit

OK.  I can make this work.  But it looks like quite a fragile scheme
to me.  What if you want to use two different libraries that both have
C callbacks?

> Since you need to call multiple SML functions, you can build C
> wrappers around MLton_callFromC that set some global integer, which
> you then dispatch on from the SML side to call the appropriate
> function.

I think that MLton.FFI should supply a centralised implementation of
this framework.  If it is OK with you, I'll implement a first cut of
the framework and contribute it to MLton (if you want it when you see
the code, that is).

> >    * Finalized values.
> 
> We're not convinced of the need for full-fledged finalization, and
> hope that weak pointers will be sufficient for your needs.

Sufficient, yes.  But not nice (for us).

> structure MLton.Weak:
>    sig
>       type 'a t
> 
>       val get: 'a t -> 'a option
>       val new: 'a -> 'a t
>    end

You might want to consider arrays of weak pointers as well (for efficiency
*and* convenience).  I'd love something like the Weak structure we
have in Moscow ML's:
        http://www.dina.dk/~sestoft/mosmllib/Weak.html


> >    * Allocation of SML aggregate values
>
> This can be handled with MLton's current infrastructure, with no need
> to allocate a dynamically sized SML structure from C.

Yes, I agree.  But as a user of the API it can be a bit cumbersome to
work with.


Thanks for the help.  We are looking forward to work with you.


Cheers,

--Ken


-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel