This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 25137 - [F+O 3.0] Identity of functions
Summary: [F+O 3.0] Identity of functions
Status: RESOLVED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 3.0 (show other bugs)
Version: Last Call drafts
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-24 16:24 UTC by Michael Kay
Modified: 2014-09-16 16:21 UTC (History)
1 user (show)

See Also:


Attachments

Description Michael Kay 2014-03-24 16:24:40 UTC
According to the definition in F+O 1.6.4, two function items are identical if

have the same name (or absence of a name), arity, function signature, and closure. (Note that there is no function or operator defined in the specification that tests whether two function items are identical.)

Although the spec claims that no reliance is placed on identity of functions, the definition is presumably there so that it can be used elsewhere, which means that it needs to be useful. We are trying to make use of it in XSLT (see bug 24478) and it causes problems because under this definition, the following two values are identical:

let $f1 := function ($x) { $x + 1 }

let $f2 := function ($x) { $x + 2 }

which in turn means that a function which returns either of these two functions at random is considered to be deterministic.

If we want a safe definition of function identity, then I suspect the only way to do it is as we do with node identity, that is, to base identity on the uniqueness of the creation event that brought the function into being. That's not a very attractive option. Another perhaps more promising approach would be to say that the two functions must have the same implementation, where comparison of implementations is left implementation-defined.
Comment 1 Michael Kay 2014-03-24 18:03:56 UTC
Another problem with the definition of identity: it appears to be aiming at a rather strong test for values being indistinguishable, for example it requires atomic values to have exactly the same type annotation, but yet it ignores some factors that are easily distinguishable but do not contribute to equality tests, such as the prefix for QName values, and the timezone for dateTime values.

It also makes NaN not identical to itself.
Comment 2 Michael Kay 2014-09-16 14:54:03 UTC
I propose to replace the text (the condition for function items being identical):

Both items are function items, and have the same name (or absence of a name), arity, function signature, and closure. (Note that there is no function or operator defined in the specification that tests whether two function items are identical.)

with:

Both items are function items, and have the same name (or absence of a name), arity, function signature, and closure, and implementations that the system is able to determine have the same effect.

Note: there is no function or operator defined in the specification that tests whether two function items are identical. Where the specification requires two function items to be identical, for example in the results of repeated calls of a function whose result is a function, then the processor must ensure that it returns functions that are indistinguishable in their observable effect. Where the specification defines behavior conditional on two function items being identical, the determination of identity is to some degree implementation-dependent. There are cases where function items are definitely not identical (for example if they have different name or arity), but positive determination of identity is possible only using implementation-dependent techniques, for example when both items contain references to the same piece of code representing the function's implementation.
Comment 3 Michael Kay 2014-09-16 16:21:14 UTC
The proposal in comment 2 was accepted and has been applied to the spec.

(For the record, comment 1 was not addressed).