Re: Performance of pattern checker on OptCoercions

Hi George, here is an even simpler design! When `-ffull-guard-reasoning` is on, use the new pattern match checker. When `-ffull-guard-reasoning` is off (the default), try to use the new pattern match checker, but if the number of guards is more than 20, 1. fall back to the old (simple) pattern match checker, and 2. issue a `too-many-guards` warning The warning can be turned off with `-Wno-too-many-guards`. What do you think? Thomas On Sat, Dec 19, 2015 at 7:52 PM, Thomas Miedema wrote:

On Mon, Dec 14, 2015 at 3:03 PM, Richard Eisenberg wrote:

...

1. -fwarn-pattern-guards=none 2. -fwarn-pattern-guards=try 3. -fwarn-pattern-guards=try-quiet 4. -fwarn-pattern-guards=do -- there is no "try"

The implementation https://phabricator.haskell.org/rGHC7e216050ce0366a1d2c2a971db457a5d49f60e8a now uses: 1. -guard-reasoning=simple 2. -guard-reasoning=try 3. -guard-reasoning=try-quiet 4. -guard-reasoning=do

Since `try-quiet` suppresses a warning, it seems more consistent with the rest of the warning machinery to have a separate warning flag for it (`-Wornate-guards`, using the new syntax from #11218), enabled by default. When the fine-grained `-Werror=...` facility is implemented (#11219), this would allow you to for example say `-Werror -Wno-error=ornate-guards`, meaning: turn all warnings into errors, except for `-Wornate-guards` (but don't silence those completely!).

So then it would like this (with `-f` prefix preferable): 1. -fguard-reasoning=simple 2. -fguard-reasoning=try 3. -fguard-reasoning=do

And orthogonal to that: -Wornate-guards / -Wno-ornate-guards (name to be decided), which only have an effect when `-fguard-reasoning=try` (the default).

Thomas