This make me ask, would it be possible and reasonable to make a rudimentary foreign-function interface using TCP sockets and serializing data to strings, instead of reinventing the FFI wheel again? True, it would be inefficient, but it would not be too difficult to do (say, using YAML [1] as the serialization format), it would give access to many libraries fast, and as a bonus you could run the library service remotely.
Ferrying complex objects with binary data over the link is not going to be pleasant in that scheme, though. And it would be difficult to conceive a generic function call protocol without reinventing RPC or SOAP.
Lo, and the apostles asked, "Do we not require an embeddable database interface?" And out of the void one was created.
And the apostles asked, "Why do we lacketh a proper Lispified object-relational manager, from whence we shall reduceth boilerplate SQL in quantity?"
And they went off and engaged in metaprogramming over strings as the ancients had so done in the land of Java, and a great darkness fell over the land.
It could be even shorter, db> doesn't need to be so complex. There's a bug in write which causes it to not flush output to a port and hence the need to flush directly, and I should be able to append the \r\n directly without doing writec. Was just getting a little tired when I got there :-)
Credit goes to Arc, and also to the C API for SQlite.
