Re: recursive imporged variable declarations

Jim Melton wrote:

> The W3C XML Query WG has considered your comment (archived at 
> http://lists.w3.org/Archives/Public/public-qt-comments/2003Nov/0186.html).  
> This message contains the official response of that WG.
> 
> We believe that your question ("Is there anything to prevent the 
> following?") is answered in the Last Call Working Draft of XQuery 1.0: 
> An XML Query Language (http://www.w3.org/TR/2003/WD-xquery-20031114/) in 
> Section 4.8, "Variable Declaration".  In that section, the third 
> paragraph contains the provision that "If an initializing expression 
> cannot be evaluated because of a circularity (for example, it depends on 
> a function that in turn depends on the value of the variable that is 
> being initialized), a dynamic error is raised."

I don't think this is a good answer.  The only reason I can think of
for requiring that a "variable may appear in the expression part of a
variable declaration only if that variable is declared or imported
earlier in the Prolog than the declaration in which it is used" is
to prevent cycles.  If you're going to require a dynamic check
for cross-module variables dependencies, that I don't see much
point in requiring variables to be defined before use.

Furthermore, requiring a dynamic cycle check seems to preclude "direct"
compilation of variable reference.  One cannot compile it to a direct 
field access, nor can variable initialization be done "eagerly" at
initialization time.  Instead, it appears that variable initialization
needs to be done lazily, on first reference, which means the compiler
must generate a function call.

Why not require a static check instead?
It is a static error if V depends on V (itself), where:
V1 depends on V2 iff V2 appears in V1's initialization expression.
V depends on F is there is a call to F in V's initialization expression.
F depends on V if V appears in the body of F.

Catching a cycle at compile time seems better than doing it at run-time.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Received on Monday, 19 January 2004 02:10:05 UTC