W3C home > Mailing lists > Public > public-qt-comments@w3.org > November 2015

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

From: <bugzilla@jessica.w3.org>
Date: Mon, 16 Nov 2015 19:04:09 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29277-523-UJ4WJ5kHsi@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29277

--- Comment #10 from Michael Dyck <jmdyck@ibiblio.org> ---
(In reply to Abel Braaksma from comment #6)
> 
> <quote>
> ...then the implementation of the function returned by the NamedFunctionRef
> is associated with the static context of this NamedFunctionRef expression
> and to the dynamic context in which it is currently being evaluated.
> </quote>
> 
> Thanks for clarifying this, I would've thought, and still think, "it"
> applies to the subject in that sentence. Simplified:
> 
> "then the X returned by Y is associated with SC and to the DC in which it is
> evaluated."
> 
> In my English-to-Dutch translation in my head, there is no way that "it" can
> refer to something other than X, i.e. the function, not the NamedFunctionRef.

(In English, one can say:
   The house is close to the city's center and to its train station.
where "its" refers to the city and not the house. Which is not to say that
quoted sentence is clear and unambiguous, just that Michael Kay is supplying a
grammatically plausible way to interpret it [which is, I believe, the way it
was intended].)


> 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?)


> Final note on function types, because I still feel like we are missing
> something. 
> 
> <quote>
> If F's implementation is implementation-dependent (e.g., it is a built-in
> function or external function or host-language-dependent function, or a
> partial application of such a function):
> </quote>
> 
> 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).)

> * function f() { 'test' } is a FunctionBody function
> 
> In your new text you suggest "built-in" functions, but I'm uncertain whether
> that means all of the above, or part of it.

Certainly not *all*, as that would include "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 other words is the set of functions referred to by §3.1.5.1 item 5.b.i
> the same as the set of functions referred to by §3.1.6?

I think it's clear that 3.1.5.1 and both the existing and suggested wordings
for 3.1.6 are all referring to the set of functions with imp-dep
implementations. (The suggested wording for 3.1.6 then adds the subordinate
clause "that depend on the static or dynamic context" and thus addresses a
subset.)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Monday, 16 November 2015 19:04:12 UTC

This archive was generated by hypermail 2.3.1 : Monday, 16 November 2015 19:04:12 UTC