Hi all, Recently, there have been some really horrible programming errors found in widely-used and security-critical libraries (GnuTLS, for example).
These libraries are usually written in C because C is a "lowest common denominator": if a library is written in C, almost every language will be able to access its functions somehow (for example, in Guile we can use the dynamic FFI). I've now realised that it would be *really awesome* to be able to write some code in Scheme, and automatically generate a .so file (or DLL) and a C header file that I could then easily (and safely) use in other programs without any special handling (including via Guile's FFI). I think it would be much easier to avoid some of these recent stupid "goto fail;" bugs if we were writing in Scheme. It seems to me that most of the things needed for this are already in place, although at some performance cost and probably some restrictions in the sort of programs that can be written in this way: - Guile can already pack bytecode into ELF object files. - Andy Wingo has demonstrated generation of simple native code from Guile (compost!). - libguile provides the infrastructure needed to load and run Guile bytecode, and we can get the dynamic linker to pull it in. So what's needed? I've had a few ideas for how this could work. Each function exported by the library needs to have a native code stub in the ELF .text section, which: a. Puts the thread into Guile mode b. Marshals the corresponding Scheme function c. Deals with uncaught exceptions - probably with SIGABRT. d. Asserts that the return value from the Scheme function is a pure foreign type e. Leaves Guile mode f. Returns Unfortunately I'm sure that I've missed some important bits (for example, thread safety & reentrancy), and I *certainly* don't have enough low-level Guile knowledge to make this work. So I'd be very interested to hear what people think about this idea. Best wishes, Peter -- Dr Peter Brett http://peter-b.co.uk/
