<div dir="ltr"><div>I suggested to Neil that he add the {-# HLINT #-} pragma to GHC. It seemed like the least worst option taking into account the various issues that have already been described in this thread. I'm OK with adding HLINT; after all we already ignore OPTIONS_HADDOCK, OPTIONS_NHC98, a bunch of other OPTIONS, CFILES (a Hugs relic), and several more that GHC ignores.<br></div><div><br></div><div>We can either</div><div>(a) not protect people from mistyped pragmas, or <br></div><div>(b) protect people from mistyped pragma names, but then we have to bake in the set of known pragmas</div><div><br></div><div>We could choose to have a different convention for pragmas that GHC doesn't know about (as Ben suggests), but then of course we don't get any protection for mistyped pragma names when using that convention.<br></div><div><br></div><div>Cheers</div><div>Simon</div><div><br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, 16 Oct 2018 at 21:12, Neil Mitchell <<a href="mailto:ndmitchell@gmail.com">ndmitchell@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> A warning flag is an interesting way to deal with the issue. On the<br>
> other hand, it's not great from an ergonomic perspective; afterall, this<br>
> would mean that all users of HLint (and any other tool requiring special<br>
<br>
Yep, this means every HLint user has to do an extra thing. I (the<br>
HLint author) now have a whole pile of "how do I disable warnings in<br>
Stack", and "what's the equivalent of this in Nix". Personally, it ups<br>
the support level significantly that I wouldn't go this route.<br>
<br>
I think it might be a useful feature in general, as new tools could<br>
use the flag to prototype new types of warning, but I imagine once a<br>
feature gets popular it becomes too much fuss.<br>
<br>
> > I think it makes a lot of sense to have a standard way for third-parties<br>
> > to attach string-y information to Haskell source constructs. While it's<br>
> > not strictly speaking necessary to standardize the syntax, doing<br>
> > so minimizes the chance that tools overlap and hopefully reduces<br>
> > the language ecosystem learning curve.<br>
><br>
> 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?<br>
<br>
Significant compilation performance penalty and extra recompilation.<br>
ANN pragmas is what HLint currently uses.<br>
<br>
>  I'm a bit skeptical of this idea. Afterall, adding cases to the<br>
> lexer for every tool that wants a pragma seems quite unsustainable.<br>
<br>
I don't find this argument that convincing. Given the list already<br>
includes CATCH and DERIVE, the bar can't have been _that_ high to<br>
entry. And yet, the list remains pretty short. My guess is the demand<br>
is pretty low - we're just whitelisting a handful of additional words<br>
that aren't misspellings.<br>
<br>
Thanks, Neil<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div></div>