[MLton-devel] mGTK for MLton

[Stephen Weeks]

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

If you don't mind to track the CVS, let's try that.  The MLton.FFI
stuff is already there.  I'll put weak pointers somewhere near the top
of my todo, and hopefully they'll be there in the next month or so.
We try to keep the CVS version as correct as possible.  If you run
into problems, feel free to send us questions.  Or, if it gets too
frustrating let us know and I'll package a snapshot.

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

Agreed that this is fragile.  I wanted to get something implemented as
quickly as possible that would be sufficient for your needs.  Now that
we have something to play with, we can over time figure out what we
want to build in terms of compiler support on top of handleCallFromC
for exporting arbitrary SML functions.

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

That sounds great.  It was my hope that with handleCallFromC in place
that we could experiment with schemes for supporting multiple C
functions and eventually build a good one into MLton.

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

With the exception of Weak.set (do you need that?), everything there
looks easily implementable in terms of MLton.Weak.  I'd say that's the
way to go for now, and if the effeciency concerns of implementing 'a
Weak.array as 'a MLton.Weak.t array becomes a problem, we'll consider
special support for it.

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

Agreed.  Much of what we do in working around this problem feels
automatable.  I'm not sure if the right solution is to build support
into MLton or build a separate tool that can generate the code.  Once
we have some infrastructure in place for exporting multiple SML
functions, we should be able to export allocators too.

I'm looking forward to seeing this all work!


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