anchor.diff:  == 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
  -|===================================================================
  +[frame="topbot",cols="2l,1a,1m", options="header,footer"]
  +|============================================================
  +|Statement template                  |Mode      |New Bindings
  +|[...] CALL proc(..) YIELD .. [...]  |In-Query  |Some
  +|[...] CALL proc(..) [...]           |In-Query  |None
  +|CALL proc(..) YIELD *               |Standalone|All
  +|CALL proc(..) YIELD ..              |Standalone|Some
  +|CALL proc(..)                       |Standalone|None
  +|============================================================
   
   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
  +  - `All`:  The call will bind all returned fields into variables
  
positive.code: before any results are returned to the user.
  An implementation may provide the user with a way to opt out of this behavior, however this must be done explicitly (e.g. via a configuration setting).
  
  ==== Semantics of explicit argument passing
  
  In this scenario, arguments are provided explicitly as a sequence of expressions as required by the procedure's signature.
  It is an error if the number of provided arguments differs from the number of arguments required by the procedure signature.
  
  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.
  
  ==== Semantics of implicit argument passing
  
  In this scenario, arguments are provided implicitly via the parameters of the Cypher statement.
  
  To call the procedure, the argument values are obtained by using the parameter in scope with the same name as the procedure argument.
  If such a parameter does not exist, the argument value is taken to be `null`.
  It is an error, if the resulting argument values are incompatible with the argument types required by the procedure  signature.
  
  == What others do
  
  
negative.code: 
  === 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 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. 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 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.
  