Mon Aug 3 11:52:09 CEST 2009
towards autowrap: replacing data structures with enumerators
So, what is needed is a clean separation between C code and external
code. This means that given a C function spec, a function that does
_not_ depend on the scripting side's memory and control model should
be automatically wrappable.
As a concrete example I'm going to take the algo_info() function in
test.c : it takes a string input argument and produces a table. This
contains the following problems:
* read data (pointer)
* write data (pointer, integer)
* suspension with communication
The idea is to turn this into a pure, non-consing C function and a
1. It is simplest to make all memory (object pointers) owned by the
external mechanism. However, this doesn't work because an
externally provided object might need to be retained during the
life of the task. The Scheme GC should just keep the args alive,
that might be simplest. This requires transitive mark().
2. How can argument passing across "yield" be abstracted properly?
C's semantics only allows a single return value, allowing yield()
do transfer only a single value. Will this get us in trouble due
to absence of containers? Is a single argument abstraction to
strong? It can always be extended using struct values, which are
quite straightforward to wrap.
See . Essentially it's about the slogan: ``C primitive shouldn't
CONS. Replace all data structures with serial protocols.''
So, I'm rediscovering concurrency-oriented programming by looking for
the simplest way to interface C code with more exotic memory and
control mechanisms. What remains is tasks + first and second order
functions! Given a set of pure C functions, wrappers that integrate
and possibly transform this code are quite straightforward to write.
In the end it sounds quite plausible: eliminate state, so the only
remaining state is the continuation!
I replaced all functions in test.c to use the new yield syntax. This
can be simplified further to traversal syntax and automatic inversion.
If I'm going this route, I do need a cheaper context switch: stack
copying is out of the question.
Also, this is worth a separate project `cprim'.