chapel-lang / chapel

a Productive Parallel Programming Language
https://chapel-lang.org
Other
1.78k stars 418 forks source link

Bug or feature: config consts can change type based on `-s` flags #11783

Open bradcray opened 5 years ago

bradcray commented 5 years ago

When a config const or config var has its value set at compile-time, the expression it's set to is essentially dropped into the Chapel code as its initializing expression. This can result in surprises. For example, given:

config const n = 1.5;

if the user compiles with -sn=100 then n will be inferred to be an integer rather than a real. This is part of the power of setting configs at compile-time (general expressions can be put into the code), but also represents a potential point of confusion or errors (the programmer obviously thought of n as a real).

This could be prevented by coding defensively:

config const n: real = 1.5;

but it seems unfortunate to recommend that programmers use types in this way for safety in a context where they're often left out for conciseness.

On the other hand, this behavior could also be considered a powerful feature since to change a 64-bit config real into a 32-bit real, I could compile with -sn=1.5:real(32) rather than the more involved:

config type ntype = real;
config const n: ntype = 1.5;

and then compiling with -sntype=real(32).

bradcray commented 5 years ago

My intuition here is to consider this a bug and to give an error if the types of a config's code-based initialization and command-line based initialization differ (or, perhaps, the latter isn't coercible to the former).

gbtitus commented 5 years ago

I suspect this originates, at least partly, with my experience which led to d3113b7b. In the aftermath of that I've decided this really is a feature, just one whose subtleties might not be fully appreciated. As such I don't think I want us to make it an error and thus outlaw it. But a warning might be worthwhile, perhaps something like 'command-line initialization changes the type of runSecs'. If I've thought this through right, I think we'd want to emit the warning if any type coercible to the type implied by the source code was not coercible to the type implied by the compiler command line initializer. Or in other words, if the compile-time initialization made some execution-time command line setting for the config illegal, where it would have been legal before.