anchor.diff:  
   The arguments of a procedure, their types, and their order are called its *argument signature*.
   
  -The result fields of returned records, their types, and their order are called its *result 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 yield records with zero result fields.
  +According to this definition, a procedure may take zero arguments and/or may produce records with zero result fields.
   
   ==== Procedure signature notation
   
  
positive.code: 
  == Proposal
  
  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.
  
  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).
  
  
negative.code: 
  - Procedures returning a stream of records: `<procName>(arguments) :: (results)`
  - Arguments and results are written as comma-separated lists of `<name> :: <type>`
  - Deprecated arguments and results are prefixed with the keyword `DEPRECATED` (i.e. written as `DEPRECATED <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>` (or `DEPRECATED <name> = <value>` respectively).
  
  ==== Procedure implementations
  
  For this proposal, it is assumed that the underlying graph database or graph processing system provides a set of concrete procedure implementations that are understood in terms of their full signatures.
  
  Procedure implementations 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 procedure implementation and provisioning are outside the scope of this proposal.
  
  === Procedure calls and invocations
  
  This proposal defines _calling a procedure_ as part of a Cypher statement (external, user-facing semantics) in terms of _invoking a procedure implementation_ (internal semantics) in the underlying graph database or graph processing system.
  
  ==== Invoking procedure implementations
  
  A procedure implementation is invoked by providing values for all required arguments and then produces arbitrarily many result records in accordance with its signature.
  
  ==== Calling procedures as part of a statement
  
  A procedure is called as part of a statement for each input record produced by a preceding clause.
  Each call is executed by invoking the concrete procedure implementation for the given procedure name using arguments derived from the input record and statement parameters.
  
  A call yields one record for each result record returned by invoking the concrete procedure implementation in the underlying graph database or graph processing system.
  
  A yielded record is formed by extending the current input record with new variable bindings.
  These new bindings are derived by computing result field projections over a given result record, the current input record, and statement parameters.
  
  We propose new syntax that introduces a new clause for calling procedures in a Cypher statement.
  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 at least one or more 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 statement (i.e. is an "in-statement call").
  In standalone calls, arguments may either be passed implicitly or explicitly.
  Standalone calls may alternatively end in `YIELD *`.
  These different calling modes are detailed in the following subsections.
  
  ==== In-statement calls
  
  Calling a procedure as part of a larger statement 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 in the `YIELD` subclause of the procedure call.
  - 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 statement without having to be aware of any other previously bound variables.
  
  As a basic example, consider a call to the procedure `myProc(name``::``STRING?``,``id``::``INTEGER?)``::`` (last``::``STRING?)`:
  
  .Calling a procedure inside a larger statement
  [source, cypher]
  ----
  MATCH (n:Person)-[r:IN]->(g:Group)
  CALL myProc(n.name, g.id * 1000 + r.id) YIELD last AS lastLogin
  RETURN *
  ----
  
  This calls `myProc` for each input record produced by the preceding `MATCH` clause with a `name` argument obtained by evaluating `n.name` and an `id` argument obtained by evaluating `g.id * 1000 + r.id`.
  Each call results in invoking the concrete procedure implementation which may produce multiple procedure result records with a single result field `last`.
  For each of them, a new record is yielded 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. has result signature `()`).
  
  ==== 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 projected fields are implicitly returned by the query.
  
  Procedures may be called standalone either using explicitly passed arguments or using implicitly passed arguments constructed from statement parameters.
  
  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.
  
  A further simplification allowed in the standalone form is to use `YIELD *` to denote that all non-deprecated result fields produced by the procedure are to be returned by the statement.
  The `YIELD *` form is _only_ allowed in the standalone form of `CALL`.
  
  Different forms of standalone calls are detailed next.
  
  ===== Calling with implicitly passed arguments (parameters)
  
  Standalone calls may omit passing arguments explicitly.  In this case, all required procedure arguments are taken implicitly from statement parameters with the same name.
  
  Again consider a call to the procedure `myProc(name``::``STRING?``,``id``::``INTEGER?)``::`` (last``::``STRING?)`:
  
  .Standalone call to a procedure using implicitly passed arguments
  [source, cypher]
  ----
  CALL myProc YIELD last AS lastLogin
  ----
  
  This is the same as executing:
  
  .Standalone call to a procedure using explicitly passed arguments
  [source, cypher]
  ----
  CALL myProc($name, {id}) YIELD last AS lastLogin
  ----
  
  Note that missing parameters are taken to be `null`.
  
  ===== Calling without specifying the names of yielded result fields
  
  Standalone calls that use the `YIELD *` subclause will always project all non-deprecated result fields.
  
  Again consider a call to the procedure `myProc(name``::``STRING?``,``id``::``INTEGER?)``::`` (last``::``STRING?)`:
  
  .Standalone call to a procedure using `YIELD *`
  [source, cypher]
  ----
  CALL myProc("Donald", 12) YIELD *
  ----
  
  This is the same as executing:
  
  .Equivalent in-statement call for standalone call to a procedure without `YIELD`
  [source, cypher]
  ----
  CALL myProc("Donald", 12) YIELD last
  RETURN *
  ----
  
  ===== Calling with implicitly passed arguments (parameters) and with `YIELD *`
  
  Both simplifications may be used in a single standalone procedure call, leading to a very concise syntax for just executing a single procedure call:
  
  .Simplified standalone procedure call
  [source, cypher]
  ----
  CALL myProc YIELD *
  ----
  
  ==== Filtering yielded records
  
  Procedure calls may optionally filter all yielded records using a `WHERE` subclause followed by a predicate.
  
  As an example, consider the procedure `querySQL(dbURI``::``STRING?, query``::``STRING?)``::`` (row``::``MAP)`:
  
  .Filtering the result from a procedure
  [source, cypher]
  