[Bug 5459] [FS] Static type analysis for the fn:abs, fn:ceiling, fn:floor, fn:round, and fn:round-half-to-even functions

------- Comment #7 from oliver@cbcl.co.uk  2008-03-31 13:31 -------
I have had another look at the specification and I have convinced myself again
that the static type analysis of abs, ceiling, round and round-half-to-even is
wrong, due to the way that function calls are bound.

Consider the following query:
abs(
  remove( (xs:integer("-1"), xs:float("-2.0")), 2 )
) instance of xs:float

The spec says [XQuery 2.2.3.1]:
 "[During the static analysis phase,] The static context is used to resolve ...
function names ... If a name of one of these kinds in the operation tree is not
found in the static context, a static error ([err:XPST0008] or [err:XPST0017])
is raised."

Along with the rules given in Formal Semantics 4.1.5 this says that during
static analysis, only a type is assigned to the function call (in this case the
type assigned is xs:float through the rules in 7.2.3), and that the function
itself is chosen when the call is evaluated and in this case the version
operating on xs:floats is selected, and so the argument is cast to a float and
the value of the query is true.

However, during static analysis it is acceptable to perform rewritings that do
not affect the value of expressions, so when static analysis of the fn:abs call
is performed the query could look like this:

abs( xs:integer(-1) ) instance of xs:float

Applying the same rules selects the xs:integer version of the function and
hence the query evaluates to false.

I suggest that the static type of the function (in the first case) should have
been inferred as xs:integer | xs:float.  This however leaves the selection of
the function used ambiguous, and so addition judgments would be required
dynamically to select the function used (similar to the current static rules).

This seems to mirror the behavior (although probably not the mechanism) used by
both our implementation and Saxon.

Received on Friday, 4 April 2008 09:59:06 UTC