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 <a.pelenit...@gmail.com> 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 <dm...@dmwit.com> 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 <b...@smart-cactus.org> wrote:
>>>
>>> Vladislav Zavialov <vlad.z.4...@gmail.com> 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-d...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
