On Feb 15, 2007, at 12:29 AM, Henry Cejtin wrote:
> For mGtk stuff I use a hash table and the uarg argument is the key (a
> Word32.word). The reason I need the hash table is to that unused
> callbacks
> can be GC'd.
Do you wrap the 'connection_id' in an object for GTK?
ie: Button.pressed: (some_method) -> connection_id
Then release the binding via the connection_id?
Unfortunately, I'm beginning to agree that it will be impossible to
build a general solution. The connection_id thing makes sense for
mGTK, but for me it does not. I also hesitate to use a hash function,
because invoking the callback must be as fast as possible, and a hash
function is probably slower than the function's body.
> chances are that only registered functions make it into the type of
> the list elements, so the dispatch will be restricted to them.
Yes, the flow analysis of MLton is extremely cool. To a C programmer
it's mind-blowing that MLton determines all the possible methods that
could be called via a "function pointer" and then switches over them.
I like it.
Speaking of which, all of the implementations proposed so far take a
two-step approach. That is, we use the uarg to find the datatype
representing the closure, then dispatch off of it. The way I see it,
we're forced to this extra level of indirection because C cannot hold
a (durable) pointer into the SML heap. This is a shame.
BTW, can MLton pack closures into an array or must it always box them?
Re _export *: is it even possible to run code that's constructed on
the heap? This sounds like a security problem, and I think some CPUs
forbid it.