5810 2008-06-26 13:19:53 +0000 [XQuery] reasoning about fn:error() 2009-03-07 06:53:43 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XQuery 1.0 Recommendation PC Windows NT RESOLVED WONTFIX P2 normal --- 1 tim jonathan.robie jim.melton jmdyck mike public-qt-comments oldest_to_newest 20924 0 tim 2008-06-26 13:19:53 +0000 There has been a long discussion in Bug 5795 about fn:error(). Many implementations will happily use lazy evaluation to avoid an error in the query: (1, fn:error())[1] Is it also permissible to avoid an error here: (fn:error(), 1)[2] ? Since fn:error has type none, whose quantifier is 1, is it conformant for count(fn:error()) to return 1? 20932 1 mike 2008-06-26 14:26:18 +0000 Since fn:error has type none, whose quantifier is 1, is it conformant for count(fn:error()) to return 1? It seems to me that you're inferring that fn:error() will return a sequence of length one, which is incorrect - it won't return at all. Is it also permissible to avoid an error here: (fn:error(), 1)[2] That seems to make the same inference that fn:error() will return a singleton - which it won't. But of course with (fn:error(), 1)[last()] returning 1 would be fine. 20935 2 tim 2008-06-26 14:34:15 +0000 > It seems to me that you're inferring that fn:error() will return a sequence of > length one, which is incorrect - it won't return at all. To be precise, I'm inferring that _if it were_ to return a result, it would return a sequence of length one (base on the quantifier). Consider instead: declare function local:mystery() as xs:integer { fn:error() }; count(local:mystery) 20937 3 mike 2008-06-26 14:56:15 +0000 >I'm inferring that _if it were_ to return a result, it would return a sequence of length one Hypotheticals are dangerous. If error() were to return a result, pigs would fly. 20939 4 tim 2008-06-26 15:01:01 +0000 > Hypotheticals are dangerous. If error() were to return a result, pigs would fly. :) Incidentally, according to FS normalization rules: (fn:error(), 1)[last()] last() gets replaced with variable $fs:last, defined as: fn:count((fn:error(), 1) ) ...so were back to the counting question. 20943 5 tim 2008-06-26 15:25:47 +0000 Another thing to consider is that type 'none' gets quite easily 'lost' during type checking. e.g. count( if ( ... ) then 1 else fn:error() ) The type of: if ( ... ) then 1 else fn:error() is xs:integer | none = xs:integer. 20965 6 tim 2008-06-27 16:13:32 +0000 According to the typing rules in Bug 4841 fs:item-at( fn:error(), Expr) is empty-sequence. as produced by (fn:error()[1]) Is this correct/desirable? Does this match the intended evaluation semantics? This may also affect fn:subsequence. Perhaps these should be defined to be of type none, i.e. erroneous? 20971 7 jmdyck 2008-06-27 20:22:33 +0000 (In reply to comment #6) > According to the typing rules in Bug 4841 > > fs:item-at( fn:error(), Expr) is empty-sequence. That could be misread as a statement about the value of the expression, so let me state more precisely that, according to those rules, the static type of fs:item-at( fn:error(), Expr) is the type 'empty'. Which implies that, if evaluated, the expression will either raise a (non-type) error, or return the empty sequence. This is consistent with the dynamic semantics: a strict evaluation will always raise err:FOER0000. (But an implementation is allowed to rewrite the expression to return the empty sequence, according to the XQuery rewrite rules.) > Perhaps these should be defined to be of type none, i.e. erroneous? Perhaps. 20984 8 tim 2008-06-30 08:03:59 +0000 Thanks Michael (Dyck). Do you have an opinion on whether count(fn:error()) is 1, and whether (more generally) it is permitted to count a function whose argument has quantifier 1 without evaluating it? 20990 9 jmdyck 2008-06-30 20:13:51 +0000 [Personal response] (In reply to comment #8) > Do you have an opinion on whether > > count(fn:error()) > > is 1, Under a strict evaluation, the expression always raises a dynamic error, so the question is more like "Is an implementation allowed to rewrite the expression into one that always returns 1?". I believe the answer is yes, but really it's allowed to rewrite it into *anything*. That is, when the original expression raises an error, the XQuery rewrite rules don't constrain the value/error resulting from the rewritten expression. (The classic example being an implementation that returns 42 for the expression 1 div 0. It's allowed, but frowned upon.) If the question is whether it's a "reasonable" or "defensible" rewrite, I'm not sure. Although FS 8.4 says quantifier(none) = 1 it's doing so in the context of defining a particular pseudo-function for use in particular rules. Applying it elsewhere isn't guaranteed to give meaningful results. (Note that FS 8.4 also says quantifier(empty) = ? which could lead to some bad inferences if mis-applied.) > and whether (more generally) it is permitted to count a function whose > argument has quantifier 1 without evaluating it? If an implementation can prove (via quantifiers or whatever) that a particular call to fn:count() would, if evaluated, either raise an error or return 1, then I believe it is permitted (among other things) to yield 1 for that expression in all cases. 24092 10 jmdyck 2009-03-07 06:53:43 +0000 At their joint meeting last week, the Working Groups endorsed my remarks in comment #9 and directed me to close this issue as resolved-WONTFIX. If you accept this resolution, please mark the issue CLOSED.