anchor.diff:  previous values instead of combining several current values.
   
   For instance, `max response_time` will compute the max of all the response_time
  -fields of all incoming tuples (until the commit-clause instruct Rigatoni to
  +fields of all incoming tuples (until the commit clause instruct Rigatoni to
   output this aggregated tuple).
   
   ===== Min, Max, Sum
  
positive.code: ===== Virtual fields
  
  In addition to the normal fields of the tuples, some tuples have 'virtual'
  fields, that is fields which value is computed rather than stored. to
  distinguish them from normal fields their name starts with a dash ('#'). Here
  is a list of all available virtual fields and which tuple they apply to:
  
  
negative.code: 
  As a selected expression one can also use `*` (star) to mean: all _other_
  fields from the input tuple (by other we mean any fields that have not be
  mentioned at all in the other expression of the select clause).
  
  The where clause is an expression, typically build from the input tuple, that
  must have a non-nullable boolean result.
  
  Semantic: for each input tuple, if the where clause is true, output the tuple
  build from the select clause. If the where clause is false then ignore the
  input tuple.
  
  ==== Aggregate
  
  Syntax:
  
  [source,sql]
  ----
    SELECT expression1 AS name1, expression2 AS name2, ...
      [GROUP BY expression3, expression4, ...]
      COMMIT WHEN commit_clause
      (FLUSH | SLIDE n | REMOVE expression | KEEP expression) WHEN flush_clause
  ----
  
  or, if `flush_clause` is the same as `commit_clause`:
  
  [source,sql]
  ----
    SELECT expression1 AS name1, expression2 AS name2, ...
      [GROUP BY expression3, expression4, ...]
      COMMIT AND (FLUSH | SLIDE n | REMOVE expression | KEEP expression)
        WHEN commit_clause
  ----
  
  The select clause is the same as above but it can use aggregate functions and,
  in addition to the `in` tuple, can refer to the `first` and `last` tuples.
  Contrary to SQL, it is not an error to take a value from the input tuple in the
  select clause with no aggregation function specified. The output tuple will
  then just use the current input tuple to get the value (similarly to what the
  `last` aggregation function would do).
  
  This is also what happens if you use the `*` (star) designation in the
  select clause. So for instance:
  
  [source,sql]
  ----
    SELECT max counter, *
      GROUP BY name
      COMMIT AND FLUSH WHEN max timestamp - min timestamp > 120
  ----
  
  would output tuples made of the maximum value of the field +counter+ (this
  field automatically named `max_counter` so explicit naming with +AS+ is not
  necessary here) and all the fields of input tuples, using the last encountered
  values.
  
  The group-by clause is a mere list of expressions that can refer to the
  <<input-tuple>>, <<first-tuple>> and <<last-tuple>>. The resulting tuple will
  be used as the key for the aggregation. When the group-by clause is omitted
  then all input tuples are aggregated together.
  
  The commit clause tells when the aggregation must be stopped and the aggregated
  tuple outputted. This is a major difference with SQL, which stops aggregating
  values when it has processed all the input. Since stream processors model an
  infinite stream of input one has to give this extra piece of information.
  
  The flush-when clause tells when an aggregate must be removed from memory. It
  is normally when you commit the tuple, so there is a shorter syntax for it:
  `...  commit and flush when ...` But the extra control allows to achieve more
  interesting operations.
  
  Additionally, instead of flushing (aka deleting the aggregated value for that
  key) it is also possible to remove some of the aggregated tuples from the
  aggregate, and keep going with new incoming tuples. This is useful to implement
  sliding windows or decay. Instead of +FLUSH+ it is possible to specify either:
  
  - +SLIDE+ followed by a positive integer, which would remove from the aggregate
    that many input tuples (the firsts that have been received);
  
  - +REMOVE+ followed by a boolean expression, for removing all those tuples from
    the aggregate;
  
  - +KEEP+ to specify which tuple not to remove (syntactic sugar for +REMOVE not
    (expression)+);
  
  Notice that +SLIDE+ assumes that the tuples are received in some meaningful
  order, which is generally not true. It is thus often safer to use a proper
  filter and use a time value (or other ordered value) from the input tuple to
  perform the selection.
  
  Also, it is important to understand that "removing" tuples from the aggregate
  requires that all received tuples that are kept for next aggregate have to be
  actually kept in memory and replayed when the aggregate is "flushed"; therefore
  this feature has quite a sizeable impact on performance, memory wise as well as
  time wise, and should be used on small aggregation operations only.
  
  Semantic: For each input tuple, compute the key and retrieve the current
  aggregate, if any. If no current aggregate exists for this key yet then start a
  new one.  Then evaluate the where clause: if it is false, skip that input (and
  discard the new aggregate that might have been created).  If the where clause
  yields true, accumulates that input into that aggregate and compute the current
  output-tuple. With all this, evaluates the commit clause: if it is true, output
  the output tuple. Also, should this input tuple be replayed when flushing this
  aggregate, store it. Evaluates the flush-when clause. If it is true, flush this
  aggregate (either by deleting the aggregate altogether or by replacing it with
  an aggregate build from replaying the stored input tuple)
  
  ==== Output
  
  