Sun Jul 4 16:44:44 CEST 2010
To build, run "make" at the toplevel.
The project uses a single Makefile for all subprojects. (Google for
"Recursive make considered harmful"). Builds are always in a separate
directory which is build/ by default (make mrproper = rm -rf build).
The project is layered, see previous posts: basic linear objects <
graph memory < interpreters. The main idea behind the project is to
enable composition of linear objects in non-linear way through a
scripting language, to provide scaffolding for a linear mostly C
I use "linear" in a sloppy way, meaning: containing only data
structures in the form of directed acyclic graphs such that
asynchronous garbage collection is not required. (see linear logic).
* LEAF: linear C objects (refcounted non-cyclic graph). Stable.
* EX: garbage-collected tree/graph memory. Stable.
* SC: simple Scheme interpreter
VM1 is a treewalking interpreter based on a CEK machine and is
fairly stable. The Scheme is incrementally bootstrapped at runtime
in a very idiosyncratic way on top of a basic C VM in the file
The VM2 is still under construction. It is a byte-code interpreted
CEK machine that would allow a more standard "big bang" bootstrap
requiring a foreign Scheme interpreter to compile the boot image.
* PF (Packet Forth or Permutation Forth, maybe even Shufflort),
A mostly-safe, linear-data Forth dialect.
Still in proof-of-concept phase. The basic idea is that execution
is linear (operations on stacks and lists), but compilation is not
(conversion from data to executable code). Somehow PF can be seen
as a metaprogrammed language where the core language is simple and
linear, and the metalanguage is nonlinear, more Scheme-like.
However, the metaprogramming is just "eval" in a global namespace.
Problems: the implementation is error-prone (linearity constraint is
not automatically enforced).