anchor.diff:  
   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
  +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
  +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.
   
  -==== Group by
  +==== Aggregate
   
   Syntax:
   
   [source,sql]
   ----
     SELECT expression1 AS name1, expression2 AS name2, ...
  -    GROUP BY expression3, expression4, ...
  +    [GROUP BY expression3, expression4, ...]
       COMMIT WHEN commit_clause
  -    FLUSH WHEN flush_clause
  -----
  -
  -The select-clause is the same as above but it can use aggregate functions and,
  -in addition to the `in` tuple, also 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
  -merely use the current input tuple to get the value (similarly to what the
  +    (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.
  -
  -The group-by-clause is a mere list of expressions that can refer to 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.
  -
  -The commit-clause tells when the aggregation must be stopped and the aggregated
  -tuple outputted.
  -
  -The flush-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
  +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 not, start a new one from the initial values of each
  -aggregate function. 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, and regardless of the commit
  -clause, evaluates the flush-clause. If it is true, deletes this aggregates and
  -forget about it.
  -
  -Note: the actual implementation cut some corners for efficiency.
  +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
   
  
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: 
  Users can check if a NULL-able value is NULL using the +IS NULL+ or +IS NOT
  NULL+ operators, which turn a NULL-able value into a boolean. This is useful
  in where clauses.
  
  +NULL+ is both a type and a value. The +NULL+ value is the only possible value
  of the +NULL+ type, or a possible value for any NULL-able type.
  