New circularity tests in prod-VarDecl

[michaelhkay]

I believe some of these new tests are incorrect, or at any rate, alternative results are legitimate.

K-InternalVariablesWith-17b expects success. But if the global variable $var1 is evaluated eagerly, evaluation fails with a circularity: local:func1() cannot be evaluated because the value depends on $var1.

K-InternalVariablesWith-17c -- the only way this can succeed is by recognising that func2() can be evaluated without evaluating its argument, and therefore without evaluating $var.

K-InternalVariablesWith-17d -- ditto.

K-InternalVariablesWith-17e -- ditto.

K-InternalVariablesWith-52 -- I think this can legitimately raise a circularity error.

[michaelhkay]

I have now got K-InternalVariablesWith-52 to work, but I'm not convinced that the spec guarantees it.

[ChristianGruen]

I believe some of these new tests are incorrect, or at any rate, alternative results are legitimate.

As we don’t enforce eager evaluation, and we allow processors to optimize the code before evaluating it, I think that the current results for K-InternalVariablesWith-17b to -17e are correct; but I agree we should add alternative errors for the test cases, which I’ll do in a minute.

I have now got K-InternalVariablesWith-52 to work, but I'm not convinced that the spec guarantees it.

It would be fine to get the specification rules straight that this one should or must not raise an error.

A corresponding paragraph in 5.16 Variable Declaration seems unclear to me (it has not changed since XQuery 3.0):

A directed graph can be built with all variable values and the context value as nodes, and with the depend on relation as edges. This graph must not contain cycles, as it makes the population of the dynamic context impossible. If it is discovered, during static analysis or during dynamic evaluation, that such a cycle exists, error [err:XQDY0054] must be raised.

It says that the graph can be built (i.e., it is optional to build it), but then, that an error must be raised if a cycle exist. Maybe it would be sufficient to say that [err:XQDY0054] must be raised if a cycle is detected – if we still want this at all?

It does not clarify yet how we want to treat declare variable $f := fn() { $f };. It is not a circular definition in the same sense as a function that directly calls itself ($f() just returns the reference to the function, creating a self-referential structure, but it doesn't lead to infinite recursion). It’s more comparable to declare function local:f() { local:f#0 }; local:f().

For functions, there is 5.18.6 Recursion, which says:

A function declaration may be recursive—that is, it may reference itself. Mutually recursive functions, whose bodies reference each other, are also allowed.

This section was introduced before function items were introduced to the language and has not been updated since then. Maybe we should include variable declarations? From today’s perspective, the distinction makes no sense anymore. Instead, it should be possible to rewrite the following code snippets (which would run infinitely) to the same identical representation:

declare function local:f() { local:f() }; local:f()

declare variable $f := fn() { $f() }; $f()