anchor.diff:  |1|7
   |2|5
   |===
  +====
   
   ==== Baseline projection
   
  
positive.code: RETURN _ex_~1~ AS _al_~1~, _ex_~2~ AS _al_~2~, ..., _ex~N~_ AS _al~N~_
  ----
  
  Accordingly, the RETURN clause
  
  .[[Q2]]Q2
  [source, cypher]
  
negative.code: While this solution works nicely for the considered examples, it is limited.
  Specifically, it only supports aggregation function in expressions of the form `_agg_(_ex_)`.
  
  Cypher, however, also allows aggregation functions to appear as sub-expression of <ProjectionItem>s, i.e. Cypher allows <ProjectionItem>s with expressions of forms, such as
  
  * `_ex_~1~ + _agg_(_ex_~2~)`
  * `_agg_(_ex_~1~) + _ex_~2~`
  * `_agg_~1~(_ex_~1~) + _ex~2~_ * _agg_~2~(_ex_~3~)`
  
  Such expressions can still be sensible and useful.
  
  .Aggregation functions a sub-expressions
  ====
  The RETURN clause
  
  .[[Q4]]Q4
  [source, cypher]
  ----
  RETURN a AS a, (a + SUM(b*c) - MIN(c)) * 2 AS foo
  ----
  
  should produce a result that is grouped by `a` and `foo` should be computed for each group as the sum of all products of `b` and `c` added to the value `a` and multiplied by two, so that result would be:
  
  .Result Q4
  |===
  |a|foo
  
  |1|32
  //(1 + (2*3 + 3*4) - 3) * 2
  |2|24
  //(2 + (3*5) - 5) * 2
  |===
  ====
  
  [NOTE]
  ====
  A less artificial example is calculating the total gross of an order as the discounted sum of line item net values (product price multiplied by amount) in query such as:
  
  .[[Q5]]Q5
  [source, cypher]
  ----
  MATCH
  (c:Customer)-[:LOCATED_IN]->(s:State)
  (c)-[:ORDERED]->(o:Order)
  (o)-[:INCLUDES]->(li:LineItem)-->(p:Product)
  RETURN s AS state, c AS customer, o AS order,
         SUM(li.amount * p.price) * c.discount * j.vat AS totalGross
  ----
  ====
  
  It has been documented on multiple occasions (e.g. cf. http://opencypher.org/articles/2017/07/27/ocig1-aggregations-article/[First oCIG Meeting]) the existing semantics or Cypher is imprecise on such queries.
  
  A precise semantics on such queries has to provide
  
  * A clear definition which <ProjectionItem>s constitute the grouping keys
  * Clear rules for which sub-expressions are allowed in <ProjectionItem>s containing aggregation functions
  
  This proposal provides a such precise semantics.
  
  == Proposal
  
  