Bugzilla – Bug 20631
[F+O 3.0] The "numeric" pseudo-type
Last modified: 2013-01-22 16:22:09 UTC
A number of functions, such as abs(), have signatures that declare the expected type and result type as "numeric". In 4.2 we explain "The word " numeric " in function signatures signifies these four types [that is, integer, decimal, float, and double]."
This informal description was fine in the past, but it falls apart once we have higher-order functions. What is the type of fn:abs#1? What happens when we supply fn:abs#1 to a function that expects function(xs:integer) as xs:double? We don't say.
With the work that we have done on unions, we can do better than this. We should say that where we use "numeric" in a function signature, we mean an anonymous type whose definition is union(xs:decimal, xs:double, xs:float). With this definition, there is no change in functionality for callers of these functions, but the semantics become clear for higher-order operations where the type of the function is significant.
Actually, it should be union(xs:double, xs:float, xs:decimal) in that order.
The current rule in the function calling rules that says
<quote>For built-in functions where the expected type is specified as numeric, arguments of type xs:untypedAtomic are cast to xs:double.</quote>
can then be removed; this will happen automatically by virtue of the existing rules applying to all union types. Because xs:double is the first type listed in the union, and because the lexical space of xs:double is a superset of the lexical space of xs:float and xs:decimal, the cast will always either return an xs:double, or will fail. So there is no change from the existing behaviour.
This issue is addressed in 3.1.6 Named Function References:
Certain functions in the [XQuery and XPath Functions and Operators 3.0] specification are defined to be polymorphic. These are denoted as accepting parameters of "numeric" type, or returning "numeric" type. Here "numeric" is a pseudonym for the four primitive numeric types xs:decimal, xs:integer, xs:float, and xs:double. For the purposes of named function references, these functions are regarded as taking arguments and producing results of type xs:anyAtomicType, with a type error raised at runtime if the argument value provided is not of the correct numeric type.
The above way of modeling polymorphic functions is semantically backwards compatible with XQuery 1.0. An implementation that supports static typing can choose to model the types of these functions more accurately if desired.
Decided to put this on the 3.1 agenda and make no change for 3.0.