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

  cd build
  make sc_vm1_test
  make sc_vm2_test

  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.

  cd build
  make pf_test

  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).