Re: completed action A-634-??: propose changes to "Evaluating Function Calls"

It's an improvement, and I think it's technically sound, but the presentation leaves an awful lot to be desired (the ordinary reader is not going to understand this section).

I think my key problems with it are:

(a) the term "implementation-defined" to characterize implementations of functions. If we replace this by, say, "native", then the text becomes much more readable. The reason is that this use of "implementation-defined" is so different from the normal way we use it in our specs.

(b) I'm unhappy that the data model gives special status to functions implemented in XQuery. It should be host language neutral. I'm uncomfortable that when you write an XSLT stylesheet, a call on an XQuery function is defined more precisely in the function call semantics than a call on an XSLT function.

(c) The way a function is implemented should be invisible. The semantics of a function call should not depend on knowing anything about the implementation. It violates encapsulation.

I think we could resolve these issues as follows:

(i) In the data model (2.8.1), replace "implementation" by two properties:

implementation: a mechanism that takes as input a binding of the parameter names to parameter values, plus the nonocal variable bindings and bound context, and which produces as output either an instance of the result type in the function signature, or a dynamic error.

bound context: an instance of a static and dynamic context (in which some or all components may be absent)

(ii) For constructs that create functions (global function declarations, inline function declarations, PFAs, named function references, etc) explain what the "bound context" is in the function that is created. For functions implemented in XPath/XQuery this will be the static context of the function body.

(iii) Move the rules for calling functions whose implementation is a FunctionBody - remove them from 3.1.5.1 into a new

3.1.5.2 User-Written Functions

The rules in 3.1.5.1 describe general rules for calling functions regardless how the function is implemented. In the case where the function is implemented as an [XQuery-only FunctionDecl or] InlineFunctionExpr, the additional rules in this section apply.

The "implementation" of the function is defined in [XDM] as "a mechanism that takes as input a binding of the parameter names to parameter values, plus the nonocal variable bindings and bound context, and which produces as output either an instance of the result type in the function signature, or a dynamic error. ". This section describes how this mechanism operates for functions implemented as an [XQuery-only FunctionDecl or] InlineFunctionExpr.

The mechanism is as follows:

       *  The  FunctionBody is evaluated, with the static and dynamic context established as follows: 

        * The static context is taken from the bound context in the function, which reflects the static context that the FunctionBody has by virtue of it being an XPath|XQuery 3.1 expression.

        * The dynamic context 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.

Note: 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.

Note: 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.

Michael Kay
Saxonica


> On 2 Mar 2016, at 04:15, Michael Dyck <jmdyck@ibiblio.org> wrote:
> 
> (Today's minutes haven't appeared yet, so I can't give the exact number or
> wording of the action item. But I was to propose alternative text for
> XQuery/XPath section 3.1.5.1 "Evaluating ... Function Calls".)
> 
> I've attached the HTML rendering for my proposal for this section
> as it appears in the XQuery doc.  (The XPath version isn't much different.)
> The diff-highlighting is for my changes relative to the CR text.
> 
> The following notes will walk you through the changes in the order they
> appear in the attachment.
> 
> Ref Bug 29277: https://www.w3.org/Bugs/Public/show_bug.cgi?id=29277
> 
> ---------------
> [5.a]
> 
> In step 5.a ("If FC is a partial function application"), where it said:
> 
>    * 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.
> 
> I changed this to:
> 
>    * implementation:
>        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.
> 
> The insertion of "If this is implementation-defined" is because if the
> implementation is a FunctionBody, you don't need to be associating it with
> contexts.
> 
> The rest of the rewording is to address some of Abel's questions in comment
> 15 of bug 29277.
> 
> ----------------------
> [5.b]
> 
> In step 5.b ("If FC is not a partial function application")...
> 
> I started with the CR text for 5.b.  Recall that there, the case analysis is
> just FunctionBody vs no FunctionBody (roughly speaking), as opposed to the
> analysis in the current editor's draft, into various kinds of function.
> 
> To help the reader, I added a sentence introducing the case analysis.
> 
> And to address the *original* problem in Bug 29277, I swapped the
> order of the two cases, as Tim Mills suggested in comment 13.
> 
> In the "FunctionBody" case:
> 
>    To help clarify the scope of this case, I added a parenthetical list of
>    function kinds.
> 
>    And I added a sentence about the static context for the evaluation,
>    since the reader might wonder why it's not mentioned.
> 
> In the "no FunctionBody" case:
> 
>    To help the reader, I linkified the various function kinds in the
>    parenthetical list.
> 
>    To address Mike Kay's concern in comment 14 of bug 29277, I applied
>    approach #2 ("the processor makes infomation available") from
>    https://lists.w3.org/Archives/Public/public-xsl-query/2016Jan/0005.html
>    (approved at meeting #628), with some wording changes.
> 
>    To fix a bug, I added F's nonlocal variable bindings as something that
>    the processor makes available to the invocation.  (This is important if
>    you have a partially applied function whose implementation isn't a
>    FunctionBody, e.g., it's derived from a built-in.)
> 
>    The minutes for meeting 628 also give some normative text as an
>    alternative to the Note I suggested. I've included that here too,
>    so people can consider it in context.
> 
> Note that this proposal is essentially orthogonal to the matter of how
> functions are partitioned into kinds, and how those kinds are named
> (see https://www.w3.org/Bugs/Public/show_bug.cgi?id=29509).  The resolution
> of that bug might have an effect on this text, but it would be minor.
> 
> 
> And while I preparing this, Mike Kay made his own proposal for 5.b:
> https://lists.w3.org/Archives/Public/public-xsl-query/2016Mar/0007.html
> so while you read this proposal you might want to have that in mind too.
> 
> -----------------------------------------------------------------------
> 
> -Michael
> <function_calls.html>

Received on Wednesday, 2 March 2016 13:57:41 UTC