Using lightning from scheme

[Ian Grant <ian.a.n.grant-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2123 bytes --]

Here is the basis of a lightning interface for Guile. The example shows
that I seem to be able to JIT compile a foreign function binding and call
it, at least once!

The rest is data that I generated using the rather awful hack at


https://github.com/IanANGrant/red-october/blob/master/src/dynlibs/ffi/testrewrite.sml

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.

Ian

I've gzipped it just to stop the mailing list sed scripts from editing it.
They don't seem to know much about programming :-)

[-- Attachment #1.2: Type: text/html, Size: 2499 bytes --]

[-- Attachment #2: example.scm.gz --]
[-- Type: application/x-gzip, Size: 11557 bytes --]

[-- Attachment #3: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Lightning mailing list
Lightning-mXXj517/zsQ@public.gmane.org
https://lists.gnu.org/mailman/listinfo/lightning