[Haskell] Treatment of unknown pragmas
Neil Mitchell
ndmitchell at gmail.com
Sun Dec 2 16:14:03 UTC 2018
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.pelenitsyn at 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 <dmwit at 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 <ben at smart-cactus.org> wrote:
>>>
>>> Vladislav Zavialov <vlad.z.4096 at 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 at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
>>
>> _______________________________________________
>> Haskell mailing list
>> Haskell at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
More information about the Haskell
mailing list