anchor.diff:  WITH AGGR(_L_)
   ----
   
  -For instance, <<Q3>> from above (`RETURN b-a AS x, SUM(b*c) AS sumBC`) can be defined as effectively equivalent to
  +.Simple rewrite semantics
  +====
  +With this semantics, the RETURN clause in <<Q3>>
  +
  +[source, cypher]
  +----
  +RETURN b-a AS x, SUM(b*c) AS sumBC`)
  +----
  +
  +is defined as effectively equivalent to
   
   [source, cypher]
   ----
   WITH b-a AS x, b*c AS sumBC
   RETURN x AS x, SUM(sumBC) AS sumBC
   ----
  +====
   
   Let's call this the _simple rewrite semantics_ for the WITH and RETURN clause.
   
  
positive.code: |2|12
  |1|15
  |===
  
  The WITH and the RETURN clauses also allow ordering and truncating the driving table, but let's ignore these aspects in this CIP.
  
  ==== Beyond baseline semantics -- simple rewrite semantics
  
  Cypher's WITH and the RETURN are syntactically more flexible when the two baseline semantics. In particular, they allow mixing aggregation and projection rather freely.
  Specifically, the WITH and the RETURN clause denoted the parameters for projection (_P_) and aggregation (_K_ and _A_) with a single nonempty set _L_ of https://raw.githack.com/openCypher/openCypher/master/tools/grammar-production-links/grammarLink.html?p=ProjectionItem[<ProjectionItem>]s `_ex_ AS _al_` where
  
  * _ex_ is an expression that is allowed to contain aggregation functions and
  * _al_ is an alias.
  
  For instance, the RETURN clause
  
  .[[Q3]]Q3
  [source, cypher]
  
negative.code: WITH POST_PROJ(_L_)
  ----
  
  .Rewrite semantics
  ====
  With this semantics, the RETURN clause in <<Q4>>
  
  [source, cypher]
  ----
  RETURN a AS a, (a + SUM(b*c) - MIN(c)) * 2 AS agg
  ----
  
  is defined as effectively equivalent to
  
  [source, cypher]
  ----
  WITH a AS a, b*c AS foo_1, c AS foo_2
  WITH a AS a, SUM(foo_1) AS foo_1, MIN(foo_2) AS foo_2
  RETURN a AS a, (a + foo_1 - foo_2) * 2 AS foo
  ----
  ====
  
  Note that the semantics proposed here also provides for the mixing of projection and aggregation that the <<simpleRewrite,simple rewrite semantics>> covers, i.e. it is a generalization of the simple rewrite semantics.
  
  .Rewrite semantics on simple mixing of projection and aggregation
  ====
  The RETURN clause in <<Q3>>
  
  [source, cypher]
  ----
  RETURN b-a AS x, SUM(b*c) AS sumBC
  ----
  
  is defined as effectively equivalent to
  
  [source, cypher]
  ----
  WITH b-a AS x, b*c AS sumBC_1
  WITH x AS x, SUM(sumBC_1) AS sumBC_1
  RETURN x AS x, sumBC_1 AS sumBC
  ----
  ====
  
  ==== Syntax restriction
  
  The rewrite does not cover all syntactically possible queries.
  
  .Aggregation *not* covered by the rewrite
  ====
  
  By the proposed semantics, the RETURN clause
  
  .[[Q6]]Q6
  [source, cypher]
  ----
  RETURN a AS a, b + SUM(c) * 2 AS foo
  ----
  
  is defined as effectively equivalent to
  
  [source, cypher]
  ----
  WITH a AS a, c AS foo_1
  WITH a AS a, SUM(foo_1) AS foo_1
  RETURN a AS a, b + foo_1 * 2 AS foo
  ----
  
  Note that variable `b` appears in the <ProjectionItem> `b + foo_1 * 2 AS foo` in the RETURN clause.
  However, variable `b` has already by removed from the driving table by the previous projections.
  In other words, the proposed rewrite produce invalid query text for <<Q6>>.
  ====
  
  
  
  // TODO syntactic restriction implied by this semantics
  // - as in https://trello-attachments.s3.amazonaws.com/5b484b125e3c6d756d136739/5ff70a2eb9fa9c57a9dbdc1e/dd4878f225c6facb6e40d700a3bbde7b/Implementation_report.pdf
  // -> The non-aggregating sub-expressions of an expression that contains an aggregation MUST be garanteed to be constant under the grouping key.
  // An implementation expected to detect by any of following situation
  // - The whole sub-expression is part of the explicitly projected grouping key (under left-associative parsing)
  // - Each operand in the sub-expression is either:
  //   - Part of the grouping key from being projected explicitly
  //   - A constant
  //   - A parameter
  
  
  === Examples
  
  