Re: recursive imporged variable declarations

Kay, Michael wrote:

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

M1:
define variable $x external;
define variable $y { if ($x) then $M2:z else 0 };
M2:
define variable $z { $M1:y };

There is a cycle iff $x is true.  So this cannot be statically checked.
But I can't think of any reason why you'd want to allow this code
without a static error.  I can't think of a valid use case for it,
and it's the kind of error you might not catch in simple testing.

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

True; we also need:
F1 depends on F2 if there is a call to F2 in the body of F1.

> Requiring this level of
> global analysis makes it very difficult to do independent compilation of
> modules,

It doesn't need to be global; the check only needs to be done within a
set of mutually dependent modules, and I don't think those can be
compiled independently anyway.  Otherwise if F references V and V is
exported by a module that doesn't (directly or indirectly) import the
current module then V cannot depend on F, so we don't care that F
depends on V.

> and it's (a) not clear to me that it's a reasonable burden to
> place on implementors,

I don't think the burden (when restricted to modules in a cycle)
is any worse than the dynamic check.

> and (b) might not disallow some useful constructs
> that appear to have a cycle, but are unproblematic if handled
> dynamically.

Do you have an example?

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

That a relevant point, but XSLT is a much more dynamic language.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Received on Monday, 19 January 2004 13:03:19 UTC