I appologize for not having allready read much of the discussion index (or
having looked into things in too much detail).

though this seems generally interesting, the spec did strike me a little
more as defining a conceptual interpreter (or at least the glue between the
physical interpreter and some general conceptual code...). this may not
necisarrily be bad (or avoidable).
I can see a number of minor bits where something like this might pose
implementation chalanges in my case...

for my project (forsaking the possibility of interpreted use of this) I had
taken a different approach:
for general glue into c, I had been using autogenerated stubs;
the stubs had called the c functions in terms of the c type system (dynamic
types were also a usable type as well though), this had allowed gluing into
a much more general base of api (most of which does not know it was not
talking with plain c);
for calling back into my implementation I had imagined generating stubs that
convert to internal types and apply with a function (possibly working in
terms of a variable).

for a lot of other things I had made use of a different property, namely,
that I am comiling to c. I had added features for generating inline c and
also for adding dynamic forms and handling type conversions.
at present I have 3 forms of inline c:
'c-top', used for inline c belonging at the top of the c output (eg: with
header includes, function defines, ...);
'c-inline', goes in the currently being generated code;
'c-exp', a c expression that evaluates to a value.

I have thus far been able to largely write a basic gl wrapper in terms of
inline c and macros (had I used the ffi or actual wrapper code there would
have been a bit more work).

additionally, the c code sees very little evidence of the language "just
over the border", thus in many cases the code is quite portable (though, in
others, the code depends on the workings of my implementation...).

a problem is that virtually none of this is actually useful for the
interpreted case though...

all for now.

--
cr88192 at hotmail dot com
http://sourceforge.net/projects/bgb-sys/
http://bgb-sys.sourceforge.net/