One problem is you have to release a new ghc every time someone comes up with a new pragma-using tool that starts to catch on. Another is that the more of these you have, the more likely a typo will inadvertently match some tool you don't even know about but ghc does.
On Tue, Oct 16, 2018 at 6:34 PM Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> wrote: > I’m still not understanding what’s wrong with > > > > {- HLINT blah blah -} > > > > GHC will ignore it. HLint can look at it. Simple. > > > > I must be missing something obvious. > > > > Simon > > > > *From:* ghc-devs <ghc-devs-boun...@haskell.org> *On Behalf Of *Simon > Marlow > *Sent:* 16 October 2018 21:44 > *To:* Neil Mitchell <ndmitch...@gmail.com> > *Cc:* ghc-devs <ghc-devs@haskell.org> > *Subject:* Re: Treatment of unknown pragmas > > > > 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 > <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01%7Csimonpj%40microsoft.com%7Cdb8a204f9dad40d006c208d633a82851%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636753194654711612&sdata=YkmmZJVadGOaWzWtSRQf18D058PdEhj8IiGwF%2B%2BGZFs%3D&reserved=0> > > _______________________________________________ > 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