RE: recursive imporged variable declarations

Personal response:

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

Mike K>I'm inclined to agree with you on this part.

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

Mike K>I don't fully understand the reasoning here. Expressions that
initialize variables, like all other expressions, can be done early (at
compile time) to the extent that the expression has no dependencies on
the dynamic context. Dynamic errors that occur during this process can
always be reported at compile time, there are rules that allow for this.
I don't see how the need to check for cyclic references inhibits static
allocation of slots to hold variable values, or static binding of
variable references to slot numbers.

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

Mike K> I don't think that's a sufficient check. V can depend on F1, F1
contains a call on F2, and F2 depends on V. Requiring this level of
global analysis makes it very difficult to do independent compilation of
modules, and it's (a) not clear to me that it's a reasonable burden to
place on implementors, and (b) might not disallow some useful constructs
that appear to have a cycle, but are unproblematic if handled
dynamically.

Per B>Catching a cycle at compile time seems better than doing it at
run-time.

Mike K>For what it's worth, we decided in XSLT 2.0 to make it a dynamic
error. XSLT is more complicated, of course, because template rule
invocations can't be bound statically.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Received on Monday, 19 January 2004 11:07:31 UTC