Treatment of unknown pragmas

[Neil Mitchell]

> 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