AtomBase
                   --------
                  Version 0.03

A set of classes inspired by the OpenCog AtomSpace, but implemented in
a simpler, lighter-weight, higher-performance fashion.  This code is
experimental, and aims to identify the required features needed for
general use in an AI/machine-learning environment.  Goals include:

-- Lockless thread safety.  This is implemented with immutable data
   structures, atomic ops, and locks, under-the-covers, where unavoidable.

-- Direct access to state.

Some desired, and generally met, goals:

-- Support for graph re-writing algorithms.  That is, data is represented
   by means of graphs; data analysis is carried out by means of graph
   re-writing algorithms.

-- Adherence to general principles of type theory and term algebra.

-- Direct representability of Bayesian networks, Markov networks.
   Allow straightforward implementation of HMM's, Viterbi algorithms,
   neural netwworks, etc.

-- Support for typed functional computing, such as typed lambda calculus.
   Blended with the probabilistic elements, this enables direct
   representation of probabilistic lambda calculs, Markvo Logic Networks.



Some of the above features are available only in the OpenCog AtomSpace,
work to migrate to here is in progress.  See also

   http://blog.opencog.org/2013/03/24/why-hypergraphs/

for a general motivational overview.


Code Overview
-------------
atom.h         -- The main atom classes
compile-base.h -- The derived classes, specific to certain atom types.
environment.h  -- Top-level atom holder, kind-of-like the OpenCog AtomSpace.
garbage.h      -- wrapper for the BDWGC garbage collector


The Environment
---------------
The primary use for the environment is to hold relations.  Relations are
more or less the same thing as OpenCog ExecutionLinks.


Memory Management
-----------------
The use of immutable data structures makes direct pointer access to
objects safe.  It also means that pointers are splurged, and that
objects are created at a rapid rate.  Tow memory management choices are
available for such a scenario: smart pointers, and garbage collection.
The current code makes use of garbage collection, using the Boehm GC.
This seems like a reasonable choice at this time.

Its possible that using C++11 shared_ptr<T>/weak_ptr<T> might be a
safer, surer, if somewhat slower and more awkward solution.