Chapel: Name executable after file containing main module, not main module itself?

[bradcray]

In issue #6283 / PR #6811, we changed the default executable name created by the compiler
from a.out to the name of the main module. Every Chapel program defines a unique main
module so this results in an unambiguous name, and often the main module takes its name
from the file containing it, so in those cases, this results in chpl testit.chpl creating an
executable named testit.

However, when the main module and the filename don't match, this can cause significant
confusion, which has led to the following counter-proposal: Perhaps we should be naming
the executable after the file containing the main module rather than the main module itself.
For a case like the following:

MyProgram.chpl:

module MyModule {
  proc main() { ... }
}

chpl MyProgram.chpl

this would result in an executable named MyProgram rather than MyModule. This should avoid some of the cases of confusion that have been reported or experienced in the current
approach.

I'm curious whether people see downsides / arguments against taking this approach. And
whether there's precedent in other languages for either our current approach or this
counterproposal that we should consider following.

[bradcray]

My only hesitation about this proposal is what the behavior should be if/when we add a
Chapel-level equivalent of include (that is, if the main module is broken across multiple files).
My instinct would be to use the name of the file that the module M declaration itself appeared
in.

[bradcray]

@ben-albrecht may be supportive of this based on his comments back on issue #6283.

[ben-albrecht]

@ben-albrecht may be supportive of this based on his comments back on issue #6283.

Yes, very supportive.

[ben-albrecht]

My only hesitation about this proposal is what the behavior should be if/when we add a
Chapel-level equivalent of include (that is, if the main module is broken across multiple files).
My instinct would be to use the name of the file that the module M declaration itself appeared
in.

I agree with this. There should always be a top-level file that contains the module M declaration or is the implicit main module.

[bradcray]

I ran into this yet again last night, so am giving myself a thumbs-up on the proposal.

[lydia-duncan]

I remain vaguely uneasy that we had a discussion on this aspect so recently, but I don't have anything specific against this particular choice. So maybe take this comment as "we really need to be more careful about our design decisions overall".

[bradcray]

While it's always regrettable to have chosen the wrong approach, it's sometimes hard to see the flaws in a proposal—or the solutions that would address those flaws—until you implement and live with them (as you know from working on initializers). Having implemented something flawed, I think it's far better to notice the flaws and address them quickly than to notice the flaws, have a proposed solution, and then avoid implementing that solution for fear of changing too rapidly. I also think that, in this case, the new solution will only reduce confusion, not increase it (and for most common use cases will have no effect).

Had someone proposed this solution on the original topic, I think it probably would've won out over the current solution at the time. However, re-reading the issue a few times, it doesn't seem to me that it even occurred to us (or at least wasn't stated clearly enough that I understood it). And it does address the uneasiness that Ben expressed very early in that issue but which we felt was just a learning curve at the time that users would need to get over. In spite of the fact that I argued in favor of the "learning curve" perspective, I've gotten bitten by this many, many times now and am not learning.

[lydia-duncan]

Having implemented something flawed, I think it's far better to notice the flaws and address them quickly than to notice the flaws, have a proposed solution, and then avoid implementing that solution for fear of changing too rapidly.

That's not the approach I'm proposing. I'm saying this is yet another example of a time when we were not careful enough about considering the ramifications of a design decision. We need to think about why we keep missing these considerations the first time around. To use an old adage, we need to "measure twice, cut once".

I am not trying to suggest that should impact our response to learning we made a mistake, beyond starting a meta conversation about decision making.

[mppf]

Having implemented something flawed, I think it's far better to notice the flaws and address them quickly than to notice the flaws, have a proposed solution, and then avoid implementing that solution for fear of changing too rapidly.

That's not the approach I'm proposing. I'm saying this is yet another example of a time when we were not careful enough about considering the ramifications of a design decision. We need to think about why we keep missing these considerations the first time around. To use an old adage, we need to "measure twice, cut once".

This to me just looks like @bradcray arguing for Agile methods and @lydia-duncan arguing for Waterfall. (grin).

But more seriously, I don't think it's reasonable to expect ourselves to always be right the first time. I think such a desire leads to slower development and still doesn't work because "experience" and/or implementation is what actually brings new information. During design, we can't generally know all of the ramifications of the decision. We can bring up potential issues, but there will always be things we didn't think of. And besides, when a potential issue is brought up (and I think this one was), it can be very hard to know how severe the issue is.

[ben-albrecht]

During design, we can't generally know all of the ramifications of the decision. We can bring up potential issues, but there will always be things we didn't think of. And besides, when a potential issue is brought up (and I think this one was), it can be very hard to know how severe the issue is.

Agreed. Taking @lydia-duncan's comment more generally as "we should learn and improve from these mistakes", I agree and think there is still a lot of room for improvement. One example that comes to mind is the previous discussions we have had about introducing a more rigorous process of putting weight on new features before they make it into the following release.

While this is a good discussion, it kind of derails the focus of this issue. Maybe it should be taken to the mailing list if there are further responses.

[bradcray]

For those following this issue: @cassella points out that an unintended consequence of the way I implemented this proposal in PR #8587 is that compiling a file foo/bar/baz.chpl is that it creates a binary called foo/bar/baz rather than simply ./baz. I believe that this is just a bug in my implementation that the testing system didn't catch, but if anyone thinks differently (i.e., that the binary shouldn't go in the current working directory), please say so. I'm going to start working on the fix in the meantime.

[cassella]

The behavior requested in this issue was implemented by the cited pr. Ready to close?