Chapel: should reduntantly named modules in import work?

[mppf]

Should something like import Library.Sub.Sub; compile or be an error?

module Library {
  module Sub {
    var x = 1;
  }
}

module Program {
  import Library.Sub.Sub;
  proc main() {
    writeln(Sub.x);
  }
}

[bradcray]

I'd think "error." Is there a compelling argument for the opposite?

[mppf]

I'm not sure about compelling but one might argue that within Sub, the symbol Sub refers to that module, and so is visible in there, and that is what Sub.Sub is seeing.

I don't have a strong opinion about this either way but it is odd.

[bradcray]

An implication of allowing it would be that the same import would have two different behaviors depending on whether Sub contained an additional submodule named Sub or not.

What's the behavior on master today?

[lydia-duncan]

If I remember right, we don't allow this for use statements.

[mppf]

If I remember right, we don't allow this for use statements.

In the 1.20 release, the following program compiled just fine:

module Library {
  module Sub {
    var x = 1;
  }
}

module Program {
  use Library.Sub.Sub;
  proc main() {
    writeln(Sub.x);
  }
}

Meaning I think we have historically allowed it.

[bradcray]

The more I think about this, the more I think we should consider it a bug. I don't think the "symbol is visible, so you can refer to it" argument holds for me because taking it to an absurd level, it might suggest that the following is legal:

module Library
  module Sub {
    record R {
     var y: int;
    }
    var myR: R;
  }
}
...
...Library.Sub.myR.Sub.myR.Sub...;  // permit myR.Sub because `Sub` is visible from within R?

Maybe more to the point, it seems like the intention of the . operator in Chapel is to dig more deeply into a nested structure/something, so to have it fail to do so seems likely to only add confusion rather than value.

[mppf]

Or this:

module Library {
  module Sub { }
}

import Libary.Sub.Library.Sub.Library; // permit Sub.Library because Library is visible from Sub?