Hi all, I've just released HLint 2.1.11 which supports three different forms of pragma as per https://github.com/ndmitchell/hlint#ignoring-hints, so you can write: * {-# ANN module "HLint: ignore Eta reduce" #-} * {-# HLINT ignore "Eta reduce" #-} * {- HLINT ignore "Eta reduce" -} The last two are new to this version of HLint. ANN is a serious performance penalty, {-# HLINT #-} triggers a GHC warning, and {- HLINT -} gets highlighted as a comment - so people get to pick their downside. I will probably remove documentation of the ANN variant at some point, since it's got serious the most serious downsides. I have no intention to support a {-@ HLINT @-} or similar syntax, because everything that might sensibly be used is taken, and even if it gets adopted universally, I suspect HLINT will account for 80%+ instances, making it still the "weird HLINT syntax". My preference is still to have GHC not give warnings on HLINT, but assuming that's still infeasible, I'll probably see about getting all the Haskell syntax highlighters to add special support for {- HLINT -}... Thanks, Neil On Sun, Oct 28, 2018 at 3:04 PM Artem Pelenitsyn wrote:

Hello Daniel,

Annotations API was discussed earlier in this thread. Main points against are:

Neil: Significant compilation performance penalty and extra recompilation. ANN pragmas is what HLint currently uses.

Brandon: The problem with ANN is it's part of the plugins API, and as such does things like compiling the expression into the program in case a plugin generates code using its value, plus things like recompilation checking end up assuming plugins are in use and doing extra checking. Using it as a compile-time pragma is actually fairly weird from that standpoint.

-- Best, Artem On Sat, 27 Oct 2018 at 22:12 Daniel Wagner wrote:

...

I don't have a really strong opinion, but... isn't this (attaching string-y data to source constructs) pretty much exactly what GHC's annotation pragma is for? ~d

On Tue, Oct 16, 2018 at 3:14 PM Ben Gamari wrote:

...

Vladislav Zavialov writes:

...

What about introducing -fno-warn-pragma=XXX? People who use HLint will add -fno-warn-pragma=HLINT to their build configuration.

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 pragmas) include this flag in their build configuration. A typical Haskell project already needs too much such boilerplate, in my opinion.

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.

Cheers,

- Ben _______________________________________________

Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

_______________________________________________ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs