anchor.diff:  
   == Proposal
   
  -This proposal consists of two parts, introducing procedures conceptually, and describing how to call them in a
  -system that supports Cypher.
  -
  +This proposal consists of two parts, introducing procedures conceptually, and describing how to call them in a system that supports Cypher.
   
   === Procedures
   
   A procedure has a name and takes a fixed number of named and typed arguments in a fixed sequence.
  -A procedure yields a stream of result records and may potentially cause a side effect.
  -
  -Each record yielded contains values for the same fixed number of named and typed fields in the same fixed sequence such that each field value in a yielded record matches its field's type.
  +A procedure produces a stream of result records and may potentially cause a side effect.
  +
  +Each record produced contains values for the same fixed number of named and typed result fields in the same fixed sequence such that each field value in a yielded record matches its field's type.
  +
  +Each result field may optionally be marked as *deprecated*.
   
   The name of a procedure, its argument names, and if applicable any result field names follow the same rules as other symbolic names in Cypher (like variables, labels, relationship types, and property keys).
   
  
positive.code: 
  - Procedures returning a stream of records: `<procName>(arguments) :: (results)`
  - Arguments and results are written as comma-separated lists of `<name> :: <type>`
  
  An actual implementation may choose to support a notion of default value for procedure arguments.
  For such a case, this CIP proposes that arguments with default values are written as `<name> = <value> :: <type`.
  
  ==== Procedure implementation
  
  In an actual implementation, procedures may be written in different programming languages and provided with APIs for accessing the underlying graph database or graph processing system as appropriate.
  The details of this are outside the scope of this proposal.
  
  === 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.
  
  When `CALL` is used within a query, `YIELD` may be followed by a `WHERE` subclause.
  This `WHERE` subclause applies _after_ the invocation of the procedure, even in the case where all the variables referenced in the `WHERE` subclause originate from before the `CALL`.
  
  Considering the procedure `querySQL(dbURI``::``STRING?, query``::``STRING?)``::`` (row``::``MAP)`:
  
  .Filtering the result from a procedure
  [source, cypher]
  
negative.code: 
  The arguments of a procedure, their types, and their order are called its *argument signature*.
  
  The result fields of returned records, their types, their order, and their deprecation status are called its *result signature*.
  
  Together, the argument signature and the result signature form the (full) *signature* of a procedure.
  
  According to this definition, a procedure may take zero arguments and/or may produce records with zero result fields.
  
  ==== Procedure signature notation
  
  