W3C home > Mailing lists > Public > public-qt-comments@w3.org > May 2016

[Bug 29586] [XQ31] The judgement subtype-itemtype(Ai, Bi)

From: <bugzilla@jessica.w3.org>
Date: Tue, 10 May 2016 18:13:30 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29586-523-9O7BesaF1l@http.www.w3.org/Bugs/Public/>

--- Comment #12 from Jonathan Robie <jonathan.robie@gmail.com> ---
(In reply to John Snelson from comment #6)
> (In reply to Tim Mills from comment #3)
> > This appears to prevent a processor from using static type analysis to avoid
> > unnecessary function coercion.  For example, I think this requires that
> > 
> > function() { 1 } instance of function() as xs:integer
> > 
> > returns false.
> I agree that your expression above should return false. I think it would be
> reasonable to allow an implementation to determine a stricter return type
> for the inline function using static typing if it can.

I'm not convinced that the specification allows this. Here's what it says about
the type of an inline function expression:

[Definition: An inline function expression creates an anonymous function
defined directly in the inline function expression.] An inline function
expression specifies the names and SequenceTypes of the parameters to the
function, the SequenceType of the result, and the body of the function.
[Definition: An anonymous function is a function created by an inline function

If a function parameter is declared using a name but no type, its default type
is item()*. If the result type is omitted from an inline function expression,
its default result type is item()*.

For other functions, it's all about the statically known function signatures:

[Definition: Statically known function signatures. This is a mapping from
(expanded QName, arity) to function signatureDM31. ] The entries in this
mapping define the set of functions that are available to be called from a
static function call, or referenced from a named function reference. Each such
function is uniquely identified by its expanded QName and arity (number of
parameters). Given a statically known function's expanded QName and arity, this
component supplies the function's signatureDM31, which specifies various static
properties of the function, including types and annotations.

So for these functions, if you know the QName and arity, you know the return

> Of course, your own static typing implementation could easily carry two
> types for the inline function expression - the "official" static type, and a
> static type for the way it behaves in practice. That would allow you to
> avoid the function coercion you were worried about.

Yes, and so far, I think that should be documented as a known incompatibility.

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Tuesday, 10 May 2016 18:13:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 10 May 2016 18:13:37 UTC