[MLton-devel] FFI

[Henry Cejtin]

I  had  another  interaction  with  Mike  later  last  night and sent him the
following slightly more detailed explanation.

>From henry  Fri Apr 12 01:05:41 2002
>Date: Fri, 12 Apr 2002 01:05:41 -0500
>From: Henry Cejtin <henry@sourcelight.com>
>To: miketh@brisbane.paradigmgeo.com, henry@sourcelight.com
>
>So  here  is a quick sketch of a really ugly implementation.  (It was a while
>ago when I did any open GL stuff, and I was certainly  only  the  rankest  of
>amature,  so  this  could  very  well have some more severe problem that I am
>missing.)
>
>The basic idea is that all the call-backs in the C world are  to  a  function
>which  sets  a globals to remember what arguments got passed to the call back
>and which call back was wanted.  Then that C function runs  some  code  which
>causes  the  glut  main-loop  to exit and returns.  (Thinks get tricky if the
>call-back was supposed to actually return  something.)   Thus  every  time  a
>call-back is fired by the open GL code, the main loop will exit.
>
>Now here is what the C code run when the ML code calls glutMainLoop:
>    Initialize the global to indicate that we really are done.
>    Call the real glut main loop.
>    Now,  (i.e.,  when  the  glut main loop returned) look at the global, and
>        return it back to the ML code which called us.
>
>The ML code now looks at what it gets.  If it is the really-done value,  then
>it knows that the glut main loop is finished.  If it isn't, then it indicates
>what to call.  It calls it (say looking up the index it  got  passed  into  a
>table of ML functions) and then calls the fake glut main loop code again.
>
>Now  all  the  ML  functions are kept on the ML side, and the calls always go
>from the ML side to the C side, with only returns coming back.  Like I  said,
>ugly,  but  modulo  the  problem  of  call-backs that need results, it should
>function.
>
>As to the general question of call backs, certainly they are  way  better  in
>functional languages, where the functions are naturally closures, rather than
>the usual faking of closures  that  most  call-back  systems  use  (an  extra
>void *), but it still is, to my mind, an inverted control structure.  You are
>forced to store all information on where you are between call backs  in  data
>structures   because   you   don't  own  the  stack.   I  hate  that.   Using
>call-with-current-continuation you can convert the current stack  into  data,
>so it isn't a horrible problem in languages that have it, but still it always
>feels very distasteful to me.
>
>Any way, does this make any sense, and does it look like it  could  work  for
>you?  I'd love to have a nice open GL interface in MLton.

_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel