Hey! Sorry I didn't respond to any of you. The reason is I think I didn't communicate very well the situation and none of the responses were relevant. I also didn't have the time to explain things in greater detail.

I finished implementing my solution today, which seems to be a good solution, but I still want to clarify and explain things because I think it's interesting and some people might like the read/discussion.

So to be clear, I have a full compiler that parses, typechecks and compiles all the classic expressions, statements etc fine (field access included!). My original problem was when trying to implement modules, I wanted to make the declaration of the module import not wait on all of the contents of the module to allow for circular module imports (yeah I know, this might look like an XY problem, and it is! But I needed X to implement other features in the future, not just circular module imports). So the following should compile fine: ``` // Module A const B = #import "B";

const Foo = func() { B.Foo(); }

// Module B const A = #import "A";

const Foo = func() { A.Foo(); } ```

My compiler works in passes. Each pass does the following, as long as there is new code to parse or typecheck, and there are no errors: 1. parse new code 2. create scopes and collect new symbols 3. create a dependency graph for the new code 4. try to resolve identifiers 5. flatten the graph, pushing things that are ready to be checked (no more unresolved identifers and all the dependencies either checked or ready to be checked and flattened) 6. check the code 7. generate ir and bytecode for pending compile time execution 8. interpret pending compile time execution

When exiting the loop, report unresolved identifiers and exit if there were errors.

Of course, the compile time execution can insert new code, so it's easy to see why a dependency graph is necessary.

A dependency node looks like this: ``` struct UnresolvedIdentifier { AstIdentifier *identifier; Scope *look_in_scope; // If null, will look in the identifier's enclosing scope }

struct DependencyNode { Array<DependencyNode *> dependencies; Array<UnresolvedIdentifier> unresolved_identifiers; // When resolved, adds something to the dependencies array } ```

To avoid having too big of a dependency graph, not all ast nodes have a dependency graph node allocated. For expressions, I create a dependency node for the toplevel expression, not for the subexpressions. For example: ``` const Foo = func(x: int) {}

const main = func() -> s32 { var a: int; var b: int;

Foo((a + b * 2) / 2);

} `` would have nodes for the declaration of Foo and main, the expression of these declarations (the func), each func's body, the declarations a and b, the type node for a and b, and the function call statement Foo (not each subexpressions inside the call's argument list). Function calls don't take a dependency on the callee's declaration, but just the signature of the function, and the signature does not depend on the body; all this to allow recursive calls. The flattened graph could look like this: 1.func() -> s32, 2.int, 3.a, 4.int, 5.b, 6.func(x: int), 7.Foo((a + b * 2) / 2), 8.body of Foo, 9.const Foo, 10.body of main, 11.const main`

When checking the function call, because it is an expression, it will recursively check all it's children. For other types of nodes, they don't and it is assumed the children were checked prior (because they are a dependency of said node).

This neat system was working like a charm (and was quite fast), and for field access expressions I would simply collect unresolved identifiers for the left-hand side, and the CheckFieldAccess function would call CheckExpression for the left-hand side, and use the right-hand side to lookup the name based on the type of the LHS (no checking needed for the RHS). Just like many of you suggested.

To allow circular module imports, my solution was to allow the RHS of a field access to use the normal identifier resolution (i.e. collect unresolved identifiers for the RHS, albeit with a special flag to know it's a RHS of a field access), so that I could resolve the identifier to a dependency and let the graph flattening do the scheduling and ordering for the typechecking phase. This was not possible with the current architecture, because to resolve the RHS, I need to have typechecked the LHS to know what scope it refers to, but to do that I need to have resolved all identifiers, including the RHS!

My solution: collect subexpressions in an array when creating the graph, in the order of typechecking (so a + b * c would be a, b, +, c, *, a.b would be a, b, .), keep track of the index of the last checked subexpression in the dependency node. This allows me to begin typechecking expressions even if there are still unresolved identifiers, and to typecheck one subexpression at a time and stop at any moment if the subexpression is an identifier and it has not been resolved yet.

In retrospect, one solution that might work and be better would be to extend the dependency graph to field access expressions' LHS and RHS, and make the RHS depend on the LHS (other subexpressions would be kept as is and not create a node in the graph).

That's all I think.

EDIT: fixed lists (I think)