Maybe the right answer is to ignore unknown OPTIONS_* pragmas and then use OPTIONS_HLINT?
On Tue, Oct 16, 2018 at 4:44 PM Simon Marlow <marlo...@gmail.com> wrote: > 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. > > We can either > (a) not protect people from mistyped pragmas, or > (b) protect people from mistyped pragma names, but then we have to bake in > the set of known pragmas > > 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. > > Cheers > Simon > > > On Tue, 16 Oct 2018 at 21:12, Neil Mitchell <ndmitch...@gmail.com> wrote: > >> > 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 >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- brandon s allbery kf8nh allber...@gmail.com
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs