How should 'require something.chpl' interact with finding the main module? about chapel

[bradcray]

Should require "something.chpl"; impact the process of identifying the main module?

My instinct (before reading the rest of the OP) would be "no"—that the intention of specializing things on the command-line w.r.t. the main module is that they are obvious candidates since the user called them out explicitly when compiling them; by contrast, I think of a require statement as a way to express dependencies that a client of the module may not necessarily be aware of, or need to be aware of, so it would seem odd if they were treated equivalently as a module on the command-line.

The one case that gives me pause is if I did chpl foo.chpl and foo.chpl contained require "bar.chpl"; Since foo.chpl is the only module the user named and contains the require, should bar be considered? Still seems odd to me, but less obvious than if, say, foo contained use Sort; and Sort.chpl contained require "bar.chpl".

Now I'll go read the rest of the OP.

Your point about the binary name being based on the main module strengthens my sense that requires shouldn't be searched for the main module.

should the module include path be consulted when processing something like require "something.chpl" or should it only be relative to the current directory?

I would think it should be consulted, for consistency with requirements of .h and .so/.a files, and because our current stance has been that require statements should talk more about what files are required than where they live on the file system (e.g., we haven't permitted require "-I …"; or require "-L …"; since the very earliest drafts of the feature.

should modules brought in as a result of require have their module initializers run even if they are not otherwise use or imported? Currently this is not the case, but that is a case where it differs from being included in the command line.

My intuition would be "no", similar to how we don't run initializers for unused modules in general (I believe).

I think the net effect of this is that we need to soften the language about require "foo.chpl"; being similar or equivalent to simply naming foo.chpl on the command-line, does that sound right?

[bradcray]

but I think it's reasonable to change that.

Me too.

Do you think we are OK here or on shaky ground?

I feel pretty fine about this personally. I think we're pretty far off the beaten path and that the current behavior could be considered dangerous/surprising if not buggy in design.

[lydia-duncan]

I generally agree that I don't think Chapel files brought in by require statements should impact the determining of the main module. I also agree that it's okay not to run the module's initializer if the module was not actually used.

The mention of tests that explicitly lock in that this is possible intrigues me though. Could you point me at them?

[mppf]

Thanks @bradcray.

We do have a test today that expects the main module to be potentially discovered through a require but I think it's reasonable to change that.

I think the net effect of this is that we need to soften the language about require "foo.chpl"; being similar or equivalent to simply naming foo.chpl on the command-line, does that sound right?

Yes, I think that's the most straightforward way to address it (as far as the spec is concerned). As I mentioned, there will be some tests we will need to update.

I am hoping that we can justify this change as clarifying the documentation & improving inconsistent behavior in a corner case. That said, it could be viewed as a breaking change. Do you think we are OK here or on shaky ground?

[mppf]

The mention of tests that explicitly lock in that this is possible intrigue me though. Could you point me at them?

One is test/modules/require/whichModsInit/bar.chpl. I do not have a list of others yet.

[lydia-duncan]

It looks like those cases were added as futures because they were confusing (#5076). I think their .good files being updated and the .future files removed might have been a mistake, I don't see any discussion on the PR that removes the .futures of whether it is appropriate to do so (sorry for missing that in my review of #18724)