When a static or dynamic function call FC is evaluated with respect to a static context SC and a dynamic context DC, the result is obtained as follows:
[Definition:
The number of Arguments
in an ArgumentList
is its arity.
]
The function F to be called or partially applied is obtained as follows:
If FC is a static function call:
Using
the expanded QName corresponding to FC's EQName,
and
the arity of FC's ArgumentList,
the corresponding function
is looked up
in the named functions component
of DC.
Let F denote the function obtained.
If FC is a dynamic function call:
FC's base expression is evaluated with respect to SC and DC.
If this yields a sequence consisting of a single function
with the same arity as the arity of the ArgumentList,
let F denote that function.
Otherwise, a type error is raised
[err:XPTY0004].
[Definition: Argument expressions are evaluated with respect to DC, producing argument values.] The order of argument evaluation is implementation-dependent and a function need not evaluate an argument if the function can evaluate its body without evaluating that argument.
Each argument value is converted to the corresponding parameter type in F's signature by applying the function conversion rules, resulting in a converted argument value.
The remainder depends on whether or not FC is a partial function application.
If FC is a partial function application
the result of the function call is a new function, which is a partially applied function.
[Definition: A partially applied function
is a function created by partial function application.]
[Definition: In a partial function application, a fixed position
is an argument/parameter position for which the ArgumentList has an argument expression (as opposed to an ArgumentPlaceholder).]
A partial function application need not have any fixed positions. A partially applied function has
the following properties (which are defined in Section
2.8.1 Functions
DM31):
name: Absent.
parameter names: The parameter names of F, removing the parameter names at the fixed positions. (So the function's arity is the arity of F minus the number of fixed positions.)
signature: The signature of F, removing the parameter type at each of the fixed positions.
implementation: The implementation of F, associated with the same contexts as in F. If these contexts are absent in F, it is associated with SC and DC. The implementation of F. If this is implementation-defined, then the new function's implementation is associated with a static context and a dynamic context: if F's implementation is associated with contexts, then those are used; otherwise SC and DC are used.
nonlocal variable bindings: The nonlocal variable bindings of F, plus, for each fixed position, a binding of the converted argument value to the corresponding parameter name.
If FC is not a partial function application, the semantics of the call depend on the nature of function F's 'implementation' property (see Section 2.8.1 Functions DM31):
If F's implementation is a FunctionBody
(e.g., F is
a user-defined function or
an anonymous function,
or a
partial application
of such a function):
The FunctionBody is evaluated.
The static context for this evaluation
is the static context that the FunctionBody has
by virtue of it being an XQuery 3.1 expression.
The dynamic context for this evaluation is obtained
by taking the dynamic context of the
module
that contains the FunctionBody, and
making the following changes:
The focus (context item, context position, and context size) is absentDM31.
In the variable values component of the dynamic context, each converted argument value is bound to the corresponding parameter name.
When
this is done,
the converted argument value retains
its most specific
dynamic type,
even though this type
may be derived from the type of the formal parameter.
For example, a function with
a parameter $p of type xs:decimal
can be invoked with an argument of type xs:integer,
which is derived from xs:decimal.
During the processing of this function
call,
the dynamic type
of $p inside the body of the function
is considered to be xs:integer.
F's nonlocal variable bindings are also added to the variable values. (Note that the names of the nonlocal variables are by definition disjoint from the parameter names, so there can be no conflict.)
The value returned by evaluating the function body is then converted to the declared return type of F by applying the function conversion rules. The result is then the result of evaluating FC.
As with argument values,
the value returned by a function
retains its most specific type,
which may be derived from the declared return type of F.
For example, a function that has
a declared return type of xs:decimal
may in fact return a value of dynamic type xs:integer.
If Otherwise, F's implementation is implementation-dependent (e.g., F is a built-in function or an external function or a partial application of such a function):
F's implementation is invoked with the converted argument values using the contexts it is associated with in F. If these contexts are absent in F, it is associated with SC and DC. in an implementation-dependent way. The processor makes the following information available to that invocation:
the converted argument values;
F's nonlocal variable bindings; and
a static context and dynamic context. If F's implementation is associated with a static and a dynamic context, then these are supplied, otherwise SC and DC are supplied.
Note:
Whether and how this information is used is, of course, entirely up to semantics that are not defined by this specification.
[[Normative alternative to the above Note, from minutes of meeting 628:]] An API used to invoke external functions must state whether the static and dynamic contexts are available to a function that is invoked. The F&O specification states how the static and dynamic contexts are available to a function that is invoked. A host language must state whether and how the static and dynamic contexts are available to a function that is invoked.
The result is either an instance of F's return type or a dynamic error. This result is then the result of evaluating FC.
Errors raised by built-in functions are defined in [XQuery and XPath Functions and Operators 3.1].
Errors raised by external functions are implementation-defined (see 2.2.5 Consistency Constraints).