[Bug 1705] [FS] technical: 5.2 Module Declaration: cyclical imports

http://www.w3.org/Bugs/Public/show_bug.cgi?id=1705





------- Comment #28 from jmdyck@ibiblio.org  2006-10-28 03:15 -------
(In reply to comment #27)
> 
> I'm thinking that the issue you mention about function declarations
> is already covered by Bug #1743.

Yes, but the proposal in Comment #23 doesn't incorporate the fix for Bug 1743.
And if you try, you'll find it doesn't quite work when multiple ("sibling")
modules share a target namespace, because statEnv.funcType won't have entries
for functions defined in the sibling modules, because the "self-import" that
would conceptually bring them in is defined (by =>stat) as basically a
no-op/pass-through.

And that's just *normalization* of FunctionCalls. You also need a properly
defined statEnv.funcType for their STA, which (in this proposal) occurs when
=>stat is applied to the merged PrologDeclList0. So you'd need to apply the fix
for Bug 1743 there too.

And note that the presence or absence of a self-import in a module does not
have the necessary effect on whether its expressions can "see" the var decls
and func decls of the sibling modules when you apply =>stat to the merged
PrologDeclList0.

> And that the typeDefn should be populated properly as it was before as
> =>prestat still propagates the static environment through the
> normalization rules as before.

Oops, yes, as =>prestat recurses down the prolog, it invokes =>stat on the
setters and accumulates the resulting statEnv, so when you get to normalizing
FunctionCalls, statEnv.typeDefn will have the types imported by the prolog.

However, because =>prestat's "output" statEnv only reflects the prolog's
setters, it's pointless, in the definition for =>module_statEnv, to use one
module's output statEnv as another's input statEnv. The input statEnvs should
all be statEnvDefault. (So in fact, there's no reason for =>prestat to have an
output statEnv at all.)

Received on Saturday, 28 October 2006 03:15:59 UTC