[Bug 29277] [XP31] Evaluating function calls does not mention evaluation of dynamic or static function calls that have no FunctionBody

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29277

--- Comment #12 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
(In reply to Michael Dyck from comment #10)
> 
> > Another suggestion is to include the word *closure* in the text, as that is
> > a commonly well understood term. Something like "the dc and sc of the
> > NamedFunctionRef expression become part of the closure of the function
> > implementation".
> 
> I think that would raise more problems than it solves. (Does every function
> implementation have a closure? What is it? Is it different from the nonlocal
> variable bindings?)

Fair enough. 

Though there is a section in XP31 that describes how functions are rewritten
using a wrapper function with the same signature (for function coercion,
actually), which I think is what most people mean with closure: a set of vars
or contextual objects that are "closed in" in the function body.


> > Let me try:
> > * fn:name is a built-in function
> > * fn:current is a host-language-dependent function
> > * ex:network-address (extension function in processor) is an external
> > function
> > * f:filter-nodes (stylesheet function) is ???
> 
> (I believe the intent was that a stylesheet function would also be
> classified as a host-language-dependent function. From the point of view of
> the XPath spec, there's no distinction between an external function and a
> host-lang-dependent function; that distinction only has meaning from the
> point of view of the host language (if any).)

I now think that the main problem lies with using the term "the implementation
of F is implementation-dependent". Colloquially, this refers to anything else
that the spec calls "implementation-dependent", but here it is specifically
meant to mean "any function that does not have a function body".

Which is still confusing, as both in XQuery and XSLT you can create a function
that has a function body that is not a FunctionBody, that is considered here as
"implementation-dependent" but that actually is very much
"user-specified/dependent".

If we "click around" we may land on the DC definition of "named functions"
which uses "implementation-dependent implementation" differently: 

<quote>
Named functions can include functions with implementation-dependent
implementations; these functions do not have a static context or a dynamic
context of their own.
</quote>

This suggests that "IDI" functions are something special with no DC/SC, where
apparently it typically means "any function, except FunctionBody functions".

> Strictly speaking, "built-in function" means "functions defined in the F&O
> spec", which would only include fn:name from your list above. However,
> Michael Kay's parenthetical goes on to more precisely define the set of
> functions addressed by the paragraph.

In the discussed section, "built-in functions" is not linked. But it has indeed
a TERMDEF. Following the definition leads (alas) to more questions:

<quote>
[Definition: The built-in functions are the functions defined in FO31 in the
<snip>FO31-namespaces</snip>] The set of built-in functions is specified by the
host language. Additional functions may be provided in the static context.
XPath per se does not provide a way to declare named functions, but a host
language may provide such a mechanism.
</quote>

This definition starts by saying exactly what it is: any function in FO31. Then
a host-language defined limitation "set of ..." is applied*, which can be
expanded by an undefined means and by "a way to declare named functions".

*) The sentence "The set of built-in functions is specified by the host
language" seems to contradict the previous statement, which says that the
built-in functions *are* the FO31 functions. I think what is meant is "A host
language may define a limitation of the whole set of built-in functions that is
available in the static context."

---------------------------------------------

I also noticed the following (related, but not mentioned here before)

1)
<quote>
Errors raised by external functions are implementation-defined (see 2.2.4
Consistency Constraints).
</quote>

--> There is no mention of "external functions" in 2.2.4. There is a mention in
D.14, again pointing to 2.2.4.

--> There is no definition of "external functions"

2)
<quote>
Errors raised by host-language-dependent functions are implementation-defined.
</quote>

--> here, and in the para before it, "host-language-dependent function" is used
as term, but has no explanation, nor does it appear elsewhere in the spec.
While the term may seem clear, it is ambiguous: FO31 is a host language of
XP31, but this is not meant. XSLT30 is a host language and I think it means
fn:current and the like, but not stylesheet functions?

3)
The term built-in functions is used 12x, of which 5x it is not linked to the
TERMDEF, of which at least 3x ought to be linked (at least in the section
discussed here).

And may I suggest an alternate wording? Because I do not think the term
"implementation-dependent implementation" has any benefit being used here, the
sole difference seems to be:

a) Functions that have a FunctionBody
b) Functions that do not have a FunctionBody

Isn't that much simpler? Together they are clearly the total set, something
that is not easily achieved using different terminology for the two sets.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 17 November 2015 15:09:55 UTC