A warning flag is an interesting way to deal with the issue. On the other hand, it's not great from an ergonomic perspective; afterall, this would mean that all users of HLint (and any other tool requiring special
Yep, this means every HLint user has to do an extra thing. I (the HLint author) now have a whole pile of "how do I disable warnings in Stack", and "what's the equivalent of this in Nix". Personally, it ups the support level significantly that I wouldn't go this route. I think it might be a useful feature in general, as new tools could use the flag to prototype new types of warning, but I imagine once a feature gets popular it becomes too much fuss.
I think it makes a lot of sense to have a standard way for third-parties to attach string-y information to Haskell source constructs. While it's not strictly speaking necessary to standardize the syntax, doing so minimizes the chance that tools overlap and hopefully reduces the language ecosystem learning curve.
This sounds exactly like the existing ANN pragma, which is what I've wanted LiquidHaskell to move towards for a long time. What is wrong with using the ANN pragma?
Significant compilation performance penalty and extra recompilation. ANN pragmas is what HLint currently uses.
I'm a bit skeptical of this idea. Afterall, adding cases to the lexer for every tool that wants a pragma seems quite unsustainable.
I don't find this argument that convincing. Given the list already includes CATCH and DERIVE, the bar can't have been _that_ high to entry. And yet, the list remains pretty short. My guess is the demand is pretty low - we're just whitelisting a handful of additional words that aren't misspellings. Thanks, Neil