which parses the output of GCC's cpp when applied to the text "#include <lightning.h>" from whence it extracts the enum declaration of lightning's opcodes, and the macros that connect the opcodes with the node-generating functions jit_new_node_* Then it tries to infer the types of the jit_new_node functions from their names, and I explicitly define the types of the instruction opcode macros on a case-by-case basis, selecting them by regexps on their names.
I hope a competent scheme programmer could get a full set of lightning primitives going in a matter of a few hours using this. They won't if I have made a lot of mistakes typing the opcode macros, but the same sort of code I used in ML could be replicated in scheme, and then they could apply the fixes in bulk. Once working, the interface could then be used to generate itself, if one were that inclined. Or it could be used to implement a lexical analyser generator, which Guile seems to need.
Anyone interested in this could look at
http://www.mpi-sws.org/~turon/re-deriv.pdf which is nicely written and gives a current perspective which seems to have benefited PLT Racket. I think it would be interesting to compile the DFAs into assembler which reads mmapped fles, or guile port buffers, or bytevectors. One could also compile the LALR tables into the same function, and I think the result would perform quite well. Have fun, but try to keep it abstract, so that the interface can be generated from the same formal spec. for EMACS lisp, say.
The same data could be used to generate a C function interface to lightning, which did more argument sanity checking than lightning's CPP macros currently do.