anchor.diff:  
   === Procedure calls
   
  -Procedures are called for each incoming record produced by preceding clauses and each time produce arbitrarily many result records. If a statement starts with a procedure call, this call is executed once, i.e. procedure calls behave similiarly to `UNWIND` regarding how they change the result cardinality.
  +Procedures are called for each incoming record produced by preceding clauses and each time produce arbitrarily many result records.
  +If a statement starts with a procedure call, this call is executed once, i.e. procedure calls behave similarly to `UNWIND` regarding how they change the result cardinality.
   
   We propose new syntax that introduces a new clause for calling procedures.
   This clause for calling procedures starts with the `CALL` keyword.
   Next follows the actual call (i.e. procedure name and arguments in signature order).
   Finally (and optionally) the clause may end with the `YIELD` keyword followed by any chosen result field projections.
   
  -A procedure call constitutes either an entire Cypher statement (i.e. is a "standalone call"), or is called as part of a larger query (i.e. is an "in-query call"). In standalone calls, arguments may be either passed implicitly or explicitly. These different calling modes are detailed in the following subsections.
  +A procedure call constitutes either an entire Cypher statement (i.e. a "standalone call"), or is called as part of a larger query (i.e. an "in-query call").
  +These different calling modes are detailed in the following subsections.
   
   ==== In-query calls
   
   Calling a procedure as part of a larger query follows three basic rules:
   
   - All arguments are always passed explicitly in the order given by the signature.
  -- Result fields are projected and appended as new variable bindings explicitly in the order given by the procedure call.
  +- Result fields are projected and appended as new variable bindings explicitly through the use of the `YIELD` keyword.
   - New variable bindings projected from result fields are not allowed to shadow existing variable bindings that are already in scope.
   
   These rules ensure that looking at a procedure call provides enough information to ascertain its impact on the variable scope in its part of the query without having to be aware of any other previously bound variables.
  
positive.code: == Appendix: Calling modes
  
  .Calling modes
  [frame="topbot",cols="3l,2a,2a,1m", options="header,footer"]
  |===================================================================
  |Statement template        |Mode      |Argument Passing|New Bindings
  |.. CALL proc(..)          |In-Query  |Explicit        |None
  |.. CALL proc(..) YIELD .. |In-Query  |Explicit        |Some
  |CALL proc(..) YIELD ..    |Standalone|Explicit        |Some
  |CALL proc YIELD ..        |Standalone|Implicit        |Some
  |CALL proc(..)             |Standalone|Explicit        |All
  |CALL proc                 |Standalone|Implicit        |All
  |===================================================================
  
  Legend:
  * Mode
    - `In Query`: The procedure call is part of a larger query (or statement)
    - `Standalone`: The procedure call forms the whole query / statement
  * Argument passing
    - `Explicit`: Arguments are passed explicitly directly after the procedure name
    - `Implicit`: Arguments are passed implicitly via the query parameters
  * New bindings:
    - `None`: The call may not bind new variables
    - `Some`: The call may bind new variables
  
negative.code: Each call may yield multiple procedure result records with a single result field `last`.
  For each of them, a new statement result record is created that contains the original variables already in scope (i.e. `n`, `r`, `g`) as well as the projected result field `last` renamed as `lastLogin`.
  
  Omitting the `YIELD` subclause means that no new variables are introduced into the scope.
  The procedure call will still affect the cardinality.
  This means that if the procedure returns 5 rows, the incoming row will be repeated 5 times.
  
  The `YIELD` subclause is *always* omitted if the procedure returns only records with no result fields (i.e. is of type `()`).
  
  ==== Standalone calls
  
  Procedures may also be called standalone, i.e. without taking arguments from or combining their results with other parts of a larger query.
  In this case, the trailing `RETURN` clause is omitted and all fields projected in the `YIELD` subclause of the `CALL` statement are implicitly returned by the query.
  A further simplification allowed in the standalone form is to use `YIELD *` to denote that all fields returned by the procedure are to be returned by the query.
  The `YIELD *` form is _only_ allowed in the standalone form of `CALL`.
  
  If the `YIELD` subclause is omitted in the standalone form of `CALL`, the semantics are the same as in the _in-query_ form, i.e. the query will not project any fields into the result, but the query will still return as many (empty) rows as produced by the called procedure.
  
  Again consider a call to the procedure `myProc(name``::``STRING?``,``id``::``INTEGER?)``::`` (last``::``STRING?)`:
  
  .Calling procedure as a standalone call statement
  [source, cypher]
  ----
  CALL myProc('Donald', $id) YIELD *
  ----
  
  The above example would call `myProc` with the constant argument `'Donald'` for the `name` parameter, and use the query parameter `id` as the `id` argument of the procedure.
  All the returned fields would then be bound and returned by the query.
  
  If we instead consider the procedure `listProcedures()``::`` (name``::``STRING?, arguments``::``STRING?, result``::``STRING?)`:
  
  .Calling procedure as a standalone call statement
  [source, cypher]
  ----
  CALL listProcedures() YIELD name AS procedure
  ----
  
  The above example would return the name of each procedure known to the system in a column called `procedure`.
  
  === Procedure call semantics
  
  