>> 4. Scheme code to talk a standardised subprocess protocol to external
>> driver binaries, written in whatever language
>
> One advantage of my proposed textual protocol is that you don't need any
> code: you just use display to give the server your bindings and query, and
> then repeatedly call read to get back the answers.  (This assumes that the
> intermediary is trusted, which it ought to be, as you are running it on
> your own machine.)

- Subprocess drivers that can be employed by languages other than Scheme
would be a big win for everyone involved.

- Being able to write drivers in C/Python/Java/... languages that don't
have a ready Scheme parser is the point.

- If a parser has to be implemented, Scheme S-expressions are not an
terrible choice, but we can make an easier and more reliable equivalent
by using length prefixes instead of escaping, and my preference would be
to also use binary.

- Scheme is a powerful language, so any encoding that's easy to
implement in C/Python/Java is even easier to implement in Scheme. And if
it's at all generic (e.g. roughly equivalent to S-expressions), it can
be repurposed for other subprocess and socket interfaces.

- Scheme syntax is intricate enough, with minor variations between
implementations, that I wouldn't just (write) or (display) things to a pipe.

- The usual rule of subprocess composition is that processes should not
trust each other to send valid data. Diligence here is good in general,
and especially good if the drivers are also used by other languages.