anchor.diff:  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`.
   
  -The `YIELD` subclause may be omitted.
  -In this case the procedure is still called; it just does not project any result fields and introduces no new variable bindings.
  -
  -The `YIELD` subclause is always omitted if the procedure returns nothing (i.e. is of type `VOID`).
  +`YIELD -` is used to indicate that no result fields should be projected.
  +In this case the procedure is still called; execution of the call just does not introduce any new variable bindings.
  +
  +However, the `YIELD` subclause is *always* omitted if the procedure returns nothing (i.e. is of type `VOID`).
   As an example, consider a call to the stored procedure `myVoidProc(name``::``STRING?``,``id``::``INTEGER?)``::``VOID`:
   
   .Calling a stored procedure that returns nothing
  
positive.code: To call the procedure, all argument expressions are evaluated to argument values in order.
  It is an error if the argument values are incompatible with the argument types required by the procedure signature.
  
  ==== Semantic details of implicit argument passing
  
  In this scenario, arguments are providede implicitly via the parameters of the Cypher statement.
  
  
negative.code: == Motivation & Background
  
  While Cypher is a very expressive graph query language, its declarative nature and scope is currently not sufficient for
  expressing certain classes of graph traversals, like traversals relying on using specialized data structures or on accessing third-party functionality.
  
  This CIP proposes to add stored procedures to Cypher in order to address these issues.
  
  