Chapel: CG: when to resolve an interface declaration?

[vasslitvinov]

main issue: #8629   related: #16411

There are a couple of things in an interface declaration that may need resolving, for example:

interface MyIFC(type T) {
  proc reqFn(arg: someExpr()) {  // when is someExpr() evaluated?
    .....                        // when is the default implementation resolved?
  }
}

(text-order) This would be similar to how a variable's initializer is resolved, ex.

var x: typeExpr() = initExpr();  // both are resolved when the var decl is encountered

(on-demand) This would be similar to how a record's contents are resolved, ex.

record R {
  type t = typeExpr();  // resolved upon a reference to the type `R`
  var x = initExpr();   // both are resolved as part of the initializer upon `new R(...)`
}

[vasslitvinov]

@bradcray suggests that variables and types have to be evaluated in order due to the fact that they are evaluating general expressions as part of their initializers. Whereas classes and records also have similar shadowing rules to variables, yet can appear before or after references to their names because they don’t have similar initializing expressions that have to be evaluated. Interfaces are more like classes and records than variables and types in this respect.

@vasslitvinov sees interface declarations closer to variable declarations in this regard, however does not have technical arguments for that.

[lydia-duncan]

I also see interface declarations as more similar to classes and records.

[bradcray]

I might summarize my position differently: I think Chapel's general philosophy is that declaration order within a scope doesn't matter, except in cases where it has to matter. For example, I can refer to a class or call a function earlier in a scope than either of them are defined. I can also refer to a module's contents before the use statement that permits me to. The cases where we don't follow this philosophy are cases where we can't support ref-before-def, like declarations of variables and type aliases.

So rather than debating whether these are more class-like or variable-like, I'd prefer to say "as with other language elements, order shouldn't matter unless that doesn't make sense / isn't workable for some reason."