`private config` variables in internal modules about chapel

[lydia-duncan]

Do you have specific cases you want to add this for? We do expose the names of some modules that are used in ChapelStandard, so I would be open to enabling it for a couple of additional ones as the need arises. It's not as though users will frequently try to name their modules things like ChapelWhatever.

I don't like the idea of only making the internal modules' names be user-facing for the purpose of configs, that seems brittle.

I worry about adding more standard module uses to internal modules - our use chains for the internal modules are already pretty gnarly and will take some dedicated effort to untangle.

[e-kayrakli]

ChapelGpuSupport is the one that's on my cache (fixing --help tests that failed because of a config const I added there at the moment). All the configs in that file can/should be used by the user in a qualified way, none should appear in base --help output.

Making them private doesn't help with the --help output, but a step towards it, I believe.

[bradcray]

Should we make internal modules' names user facing?

Independent of this issue (but also related to it), I don't think we should, and in fact think we should be doing more to prevent the user from being able to refer to them. Specifically, I don't think the user should be aware that the internal modules exist or be aware that they do exist. We should feel free to move the implementations of things in those modules into the compiler, into another internal module, rename the internal modules, etc. So making their names user-facing would go against this big-time (in fact, I'd love to see us remove the user's ability to refer to an internal module name prior to 2.0 if possible).

W.r.t. the specific issue of --help output, I'd probably be inclined to not print internal module config names in --help output by default—requiring some other flag to see them (like a --devel equivalent or having CHPL_DEVELOPER set).

[lydia-duncan]

in fact, I'd love to see us remove the user's ability to refer to an internal module name prior to 2.0 if possible

The vast majority of them can't be named today after Michael's change to make use statements only bring in the name with a rename. The only uses in ChapelStandard that enable it are the uses of ChapelIO, Errors, Types and AutoMath. I had forgotten that ChapelIO was a standard module and not an internal one, so all of the modules that expose their names are actually standard modules

[bradcray]

The vast majority of them can't be named today after Michael's change to make use statements only bring in the name with a rename.

I think we can write:

use ChapelBase;

today and have it compile and run without an error. That's something I think we should put a stop to (i.e., user code referring to internal module names should generate an error).

[lydia-duncan]

Hmm. I'm not sure how I feel about that. I agree that it would be nice to make it so that users can't access those names, but I worry a bit about the implications of implementing it. I can think of two strategies off the top of my head:

1. Just hard code a check against the flag we use to denote an internal module and ensure it doesn't get called in user code.

• I don't like this as much. It'd be simple, but I feel like it could be brittle and developers in module code would get confused pretty easily about when they can and can't use the module name

2. We could add a pragma for those module names to indicate that they shouldn't be callable, either in user code or outside of modules (or uses) decorated with another pragma to indicate it was okay.

• This is slightly more work (though not much), could have the same brittleness in the implementation but does make it obvious when you can and can't use the module name. So I think I'd prefer this strategy

[bradcray]

developers in module code would get confused pretty easily about when they can and can't use the module name

This is what I would do. I expect that developers don't find themselves wanting to type the names of internal modules very often, and that most of the time when they want to, it's within the internal modules themselves. I also think we should be optimizing for the productivity of the end-user rather than the developer (and think we could generate a specialized error when --devel is being used to explain the rules if a developer inadvertently tries to name an internal module).