Chapel: Should setting private configs on the command line require the module name?

[ronawho]

Currently, private configs can be set on the command line without specifying the module name, but I wonder if it would make more sense to always require the module name for private configs. e.g. for:

module M1 {
  private config const v = false;
}

module M2 {
  use M1;
  config const v = false;
  proc main() { writeln(v); }
}

$ ./test --v
<command-line arg>:1: error: Configuration variable 'v' is defined in more than one module.  Use '--help' for a list of configuration variables and '-s<module>.v' to disambiguate.

Should non qualified configs setting on the command line only work for public configs, and the above test should work, setting v in M2?

[mhmerrill]

this is currently happening with the arkouda server. we expected this feature to work and are using it a bit. Hoping forprivate config const it to disambiguate between the same config const in different modules.

$ ./arkouda_server --logging=true --memTrack=true --v=false --SegStringSort.v=true
<command-line arg>:3: error: Configuration variable 'v' is defined in more than one module.  Use '--help' for a list of configuration variables and '-s<module>.v' to disambiguate.

[bradcray]

I think this is an intriguing proposal. The reason that private is not interpreted this way today is that private typically only means "cannot be referred to outside of the scope in which it was declared." So, for example, M1 can refer to M2.v, but M2 cannot refer to M1.v.

At the same time, we didn't want to go so far as saying "a private config can't be set on the command-line because that would mean private config has no purpose (since the whole point of a config is to be able to set it on the command-line).

I interpret your proposal as suggesting that public configs should be more accessible on the command-line than private configs such that in the case of ambiguity, public wins. As stated above, I think that's an intriguing proposal.

An extension to this might be that private configs should also not be listed in a Chapel program's default --help output. I.e. they're essentially "undocumented" configs from the perspective of the program's default behavior.

[mhmerrill]

I'd be ok with the private configs always needing to be fully qualified and the non private ones get mapped to their name like:

prog --M2.v=true --v=false

I still think that the private ones should be in the default --help output annotated with the private to flag the they should be used with a fully qualified name.

[e-kayrakli]

I like what is proposed here.

Only:

An extension to this might be that private configs should also not be listed in a Chapel program's default --help output. I.e. they're essentially "undocumented" configs from the perspective of the program's default behavior.

I think they should be documented (with their appropriate qualifiers). Because I see config-ness and private-ness as more or less orthogonal to one another. Maybe the --help behavior can be tied to something else like a pragma "no help" or something.

[bradcray]

Since response to this idea was fairly positive, I took a quick look to see what it would take to put it together and got it working in about 1/2 hour's time. We should do a more formal straw poll to make sure it doesn't give anyone pause before proceeding, but assuming nobody balks or causes us to second-guess the idea, I think this could easily be part of Chapel 1.21.

[bradcray]

I'd be ok with the private configs always needing to be fully qualified and the non private ones get mapped to their name like

I think that if there's only one private config in a program named debug that it should be OK to say --debug=false rather than requiring --M.debug=false (say), given that there's no need to disambiguate. Specifically, nothing about private's definition in Chapel today indicates that full qualification must be used to access the variable, so it seems surprising to me that it would here. That's why I've been viewing the proposed change as giving preference to public over private in the case of command-line ambiguity. Any thoughts on that?

[bradcray]

Thinking about this an hour more, though, I can also see merit to the proposal to require private configs to always be qualified on the command-line:

It could make a program's command-line behavior more stable as additional modules are added. For example, if I've got a module with a private config debug and am using --debug=true to set it, but then later bring in a library module with a public config debug, the behavior of my program would change since the public variable would start winning. Whereas if qualified modifiers were always required for setting private configs, I would've been using --MyModule.debug=true from the beginning.

So I think I could imagine going either way on this.

[lydia-duncan]

I still kinda wonder if we should allow config variables to be private at all, since they are designed to be set "outside" the module in which they are defined (so kinda violating the notion of private). To me, qualified naming a private anything seems weird, but a necessary evil to allow setting private config variables. I don't have a strong feeling for whether we should require qualified naming, or sometimes allow unqualified naming - I find both of those arguments compelling, and if I had to choose would probably go with "qualified only" as going to that strategy later from "qualified sometimes" is a backwards breaking change.

[e-kayrakli]

Initially I also found private config to be contradictory. But, now I view private only in terms of scope of the variable, and config as just a way for the user of the application to control it. So I see the awkwardness but I think we should keep supporting them.

I cast my vote for qualified access only because it prevents confusion, Lydia's backward compatibility argument also resonates with me. My only worry for that is whether it would force the programmer too much while choosing module names to make their config variables easy to control. But if anything, it would force them to exercise better programming practices...

[bradcray]

since they are designed to be set "outside" the module in which they are defined (so kinda violating the notion of private)

This doesn't give me pause for the following reason: The variable is still being set within the module, it's just taking its initial value from something outside of the module. View private config var x = 42; as being rewritten as:

private var x = if setOnCommandLine("x") then commandLineValue("x") else 42;

Yes, the command-line is referring to x even though it's private, but it's not really part of the code, so sortof "above it all."

if I had to choose would probably go with "qualified only" as going to that strategy later from "qualified sometimes" is a backwards breaking change.

Good point.