This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In function-literal-707 we have $a depending on $f, $f depending on local:plus#2 and local:plus depending on $a. How is this not a XQDY0054 cycle? Just because it calls not local:plus? But in general it is undecidable, if a dynamic reference gets called. Especially, since it could involve the context item, which could depend on anything. The opposite happens in fn-function-lookup-613
We very deliberately made cyclicity a dynamic error rather than a static error to permit this kind of construct. Yes, it's not statically decidable whether something gets evaluated, but it is dynamically decidable. Evaluating function-arity(F) does not involve evaluating F (it cannot involve calling F, because no arguments have been supplied); so the dynamic evaluation of this query involves no circularity. By contrast, in function-lookup-613, dynamic evaluation is not possible. Given declare variable $v := function-lookup($n, 0)(); declare function local:return-v() {$v + 1}; we can't evaluate $v without calling local:return-v (note the "()") and we can't evaluate local:return-v() without evaluating $v.
Well, I just spent two days changing my dynamic cycle checker to a static cycle checker, so it would be more efficient....
Actually my old cycle checker was half dynamic (choosing the order of the evaluation) and half static (checking each declaration statically), and thus the latter half could not handle these two cases either. But a fully dynamical cycle checker crashes on K2-InternalVariablesWithout-1a, because it gets stuck in the endless recursion of declare function local:myFunction() { local:myFunction(), 1, $local:myVar }; before it ever reaches $local:myVar , (actually that test was the reason, I made it half statically in the first place https://github.com/benibela/internettools/commit/bed837e9a111befbf517fa2e3ab59bbfed6bcfbf ) Endless loop detection does not seem to be decidable either
Interesting. Yes, I agree that it would be perfectly reasonable with K2-InternalVariablesWithout-1a to go into infinite recursion rather than detecting the error. Saxon is rejecting this one during a static check, which is a residue of XQuery 1.0 (which we still support, just about). Looking at the code, the static check is actually too strong: it's capable of rejecting things that wouldn't fail at run-time. Our static check appears to treat variable references and static function calls as if they are always evaluated. Reading the rules, I don't think that's conformant; the rules for conditional expressions and switch/typeswitch don't allow you to raise an error as a consequence of evaluating a branch of a conditional that isn't actually selected.
This also happens in K2-InternalVariablesWithout-6a K2-InternalVariablesWithout-7a K2-InternalVariablesWithout-8a
I have committed fixes to the other test cases mentioned in comment #5