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.

> 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)

>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.

> 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.

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.

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?

(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.

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?

[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.

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.