On Mon, Mar 11, 2013 at 9:33 PM, Isaac Dupree
On 03/11/2013 07:04 PM, Simon Peyton-Jones wrote:
Aha. It is indeed true that
ghc -fdefer-type-errors -w
does not suppress the warnings that arise from the type errors; indeed there is no current way to do so. How to do that?
To be kosher there should really be a flag to switch off those warnings alone, perhaps -fno-warn-type-errors
So then -fwarn-type-errors is on by default, but is only relevant when -fdefer-type-errors is on. Once -fdefer-type-errors is on, -fno-warn-type-errors and -fwarn-type-errors suppress or enable the warnings. -w would then include -fno-warn-type-errors.
GCC has a concept -Werror=unused-variable for example: each warning can be disabled, a warning, or an error. If GHC had that, we could have "type-errors" be a warning whose default state is -Werror. That's cleaner in a certain way, but it also seems fishy. Just throwing the idea out there.
I don't know which way GHC would like to go, but I can comment on the GCC feature as I have direct experience here. For a long time I was very reluctant to the fine-grained warning categories; rather I preferred a much coarser grained warning categories; my thinking was that "warnings or questionable coding practices" come in cluster (I still do.) Remember that the more nobs you give user to control the compiler, the larger your test matrix becomes and the higher is the probability of untested and/or incoherent compiler switch combinations. However, several fellow GCC developers felt otherwise -- many citing the pressure of the "competition" (e.g. icc, clang, etc.), so I eventually gave in but under the condition that we still maintain the coarse-grained warning categories (e.g. -Wall, -Wextra, etc.) and display in the diagnostics how users are to turn off a specific warning they did not like. I suspect that if users frequently need to turn off a warning, then that warning should probably be off by default. Most users rarely want to specify long (and arcane) command lines; very few want to litter their otherwise pretty programs with lines of pragmas (no matter how much effort was spent in designing the syntax.) -- Gaby