anchor.diff:  
   == Overview
   
  -Ramen is a _stream processor_. Unlike other stream processors that are designed
  -to scale to many servers, Ramen is designed to be efficient on a single (or
  -very few) servers. In other words, it is not designed to be distributed. As a
  -trade off, what we gain from relaxing this constraint is a much simpler design
  -and faster program.
  -
  -Ramen is composed by a central server that serves an API allowing clients to
  -edit the configuration. This configuration consists of a graph of operations,
  -each of which is given using a specialized high level language that's inspired
  -by SQL and alleviate users to program the operations in actual programing
  -languages. These operations are then compiled by the central server down to
  -machine code into individual programs for faster execution. Also, events sent
  -from one operation to the next are sent directly from the emitter to the
  -recipient using memory-mapped ring-buffers, thus avoiding another source of
  -complexity and latency.
  -
  -The last design principle is that events must be _tuples_ of primitive types,
  -with no special field, and are statically typed; not unlike tuples from a SQL
  -database.  Therefore, each node has an input and an output type: the types of
  -event they accept and produce.
  +Ramen is a non-distributed _stream processor_.
  +
  +Unlike other stream processors that are designed to scale to many servers,
  +Ramen is designed to be efficient on a single (or very few) servers.
  +
  +It is composed of a central program that serves an API allowing clients to edit
  +the configuration. This configuration consists of a graph of operations, each
  +of which is given using a specialized high level language inspired by SQL.
  +These operations are then compiled by the central server down to machine code
  +into individual programs, the _workers_, for parallel execution.
  +
  +Each worker accepts input of a given type and produces output of a given type,
  +not unlike SQL rows being consumed by a SQL query that produces other rows used
  +as input to a sub query. As in SQL, each row is a _tuple_ of primitive types.
  +This stream of tuples flows directly from one worker to the next using
  +efficient memory-mapped ring buffers.  All those tuples are statically typed at
  +compile time to avoid runtime crash and improve speed.
   
   == Glossary
   
  
positive.code: [source,sql]
  ----
    SELECT avg salary, *
    FROM employee GROUP BY age, is_make
  ----
  
  ...would output tuples made of the average value of the input field +salary+
  
negative.code: global lifespan or a per-group lifespan. The default lifespan for aggregate
  functions is the group and the default lifespan for other stateful functions is
  global.  Add "globally" after the function name to force it to use the global
  lifespan and "locally" to force the per-group lifespan. For instance, the `sum`
  function, being an aggregate function, use a group-wise state by default,
  meaning +sum x+ is equivalent to +sum locally x+. To make it use a global state
  (and build the sum over all incoming tuples regardless of how they are
  grouped), write: +sum globally x+.
  
  ===== Boolean operators
  
  