This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.
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/