Semantics of function calls

I think this problem might be easier to solve if instead of trying to enumerate all the possible kinds of function under the section on function calls, we devolve responsibility to the definitions of different classes of function to say what happens when they are called.

This occurred to me when considering what happens when XPath invokes an XQuery-defined function using load-xquery-module(). It doesn't make sense for the XPath spec to have to assign the resulting function to one of its categories and explain the call semantics; it's up to XQuery to say what happens when an XQuery-defined function is called.

From this perspective the function invocation mechanism is completely generic:

* The supplied arguments are converted to the required types using the function call rules

* The implementation of the selected function is supplied with the converted arguments together SC and DC (in the general case these are available, but some kinds of function choose not to expose them)

* The implementation either returns a value or throws an error

* If it returns a value this is converted to the declared return type (the calling mechanism can bypass this step if it knows that no conversion will be necessary).

Since further particulars are devolved, we need say nothing about cases that are outside the responsibility of our spec ("host language functions", "external functions", etc). We say what information is available to them, and they can do what they like with it.

Michael Kay
Saxonica

Received on Tuesday, 9 February 2016 22:28:45 UTC