Re: recursive imporged variable declarations

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

I also think so, but IMHO the rule 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"   - this rule prevents cycles not only _inside _a module,
but also _across_ two or more modules.

Therefore a cycle would anyway be detected during static analysis.
But perhaps there are implementation-dependent issues that I don't see ?

Per Bothner wrote:

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