Re: [Haskell] Treatment of unknown pragmas
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-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
Re: [Haskell] Treatment of unknown pragmas
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
Re: [Haskell] Treatment of unknown pragmas
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 signature.asc Description: PGP signature ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
Re: [Haskell] Treatment of unknown pragmas
I like the suggestion of a flag. For any realistic compilation you
have to pass a large number of flags to GHC anyway. `stack`, `cabal`
or so on can choose to pass the additional flag by default if they
wish or make it more ergonomic to do so.
On Tue, Oct 16, 2018 at 7:58 PM Jared Weakly wrote:
>
> The main problem I see with this is now N tools need to implement support for
> that flag and it will need to be configured for every tool separately. If we
> standardize on a tool pragma in the compiler, all that stays automatic as it
> is now (a huge plus for tooling, which should as beginner friendly as
> possible). It also, in my eyes, helps enforce a cleaner distinction between
> pragmas as a feature-gate and pragmas as a compiler/tooling directive
>
> On Tue, Oct 16, 2018, 11:13 AM Vladislav Zavialov
> wrote:
>>
>> What about introducing -fno-warn-pragma=XXX? People who use HLint will add
>> -fno-warn-pragma=HLINT to their build configuration.
>>
>> On Tue, Oct 16, 2018, 20:51 Ben Gamari wrote:
>>>
>>> Hi everyone,
>>>
>>> Recently Neil Mitchell opened a pull request [1] proposing a single-line
>>> change: Adding `{-# HLINT ... #-}` to the list of pragmas ignored by the
>>> lexer. I'm a bit skeptical of this idea. Afterall, adding cases to the
>>> lexer for every tool that wants a pragma seems quite unsustainable.
>>>
>>> On the other hand, a reasonable counter-argument could be made on the
>>> basis of the Haskell Report, which specifically says that
>>> implementations should ignore unrecognized pragmas. If GHC did this
>>> (instead of warning, as it now does) then this wouldn't be a problem.
>>>
>>> Of course, silently ignoring mis-typed pragmas sounds terrible from a
>>> usability perspective. For this reason I proposed that the following
>>> happen:
>>>
>>> * The `{-# ... #-}` syntax be reserved in particular for compilers (it
>>>largely already is; the Report defines it as "compiler pragma"
>>>syntax). The next Report should also allow implementations to warn in
>>>the case of unrecognized pragmas.
>>>
>>> * We introduce a "tool pragma" convention (perhaps even standardized in
>>>the next Report). For this we can follow the model of Liquid Haskell:
>>>`{-@ $TOOL_NAME ... @-}`.
>>>
>>> Does this sound sensible?
>>>
>>> Cheers,
>>>
>>> - Ben
>>>
>>>
>>> [1] https://github.com/ghc/ghc/pull/204
>>> ___
>>> ghc-devs mailing list
>>> ghc-d...@haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>> ___
>> ghc-devs mailing list
>> ghc-d...@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> ___
> 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
Re: [Haskell] Treatment of unknown pragmas
I rather agree.
We don't even need a convention do we? /Any/ comment in {- -} is ignored
by GHC /except/ {-# ... #-}. So tool users are free to pick whatever
convention they like to identify the stuff for their tool.
Simon
| -Original Message-
| From: ghc-devs On Behalf Of Ben Gamari
| Sent: 16 October 2018 18:51
| To: GHC developers ; haskell@haskell.org
| Subject: Treatment of unknown pragmas
| Hi everyone,
|
| Recently Neil Mitchell opened a pull request [1] proposing a single-line
| change: Adding `{-# HLINT ... #-}` to the list of pragmas ignored by the
| lexer. I'm a bit skeptical of this idea. Afterall, adding cases to the
| lexer for every tool that wants a pragma seems quite unsustainable.
|
| On the other hand, a reasonable counter-argument could be made on the
| basis of the Haskell Report, which specifically says that
| implementations should ignore unrecognized pragmas. If GHC did this
| (instead of warning, as it now does) then this wouldn't be a problem.
|
| Of course, silently ignoring mis-typed pragmas sounds terrible from a
| usability perspective. For this reason I proposed that the following
| happen:
|
| * The `{-# ... #-}` syntax be reserved in particular for compilers (it
|largely already is; the Report defines it as "compiler pragma"
|syntax). The next Report should also allow implementations to warn in
|the case of unrecognized pragmas.
|
| * We introduce a "tool pragma" convention (perhaps even standardized in
|the next Report). For this we can follow the model of Liquid Haskell:
|`{-@ $TOOL_NAME ... @-}`.
|
| Does this sound sensible?
|
| Cheers,
|
| - Ben
|
|
| [1] https://github.com/ghc/ghc/pull/204
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] Treatment of unknown pragmas
Hi everyone,
Recently Neil Mitchell opened a pull request [1] proposing a single-line
change: Adding `{-# HLINT ... #-}` to the list of pragmas ignored by the
lexer. I'm a bit skeptical of this idea. Afterall, adding cases to the
lexer for every tool that wants a pragma seems quite unsustainable.
On the other hand, a reasonable counter-argument could be made on the
basis of the Haskell Report, which specifically says that
implementations should ignore unrecognized pragmas. If GHC did this
(instead of warning, as it now does) then this wouldn't be a problem.
Of course, silently ignoring mis-typed pragmas sounds terrible from a
usability perspective. For this reason I proposed that the following
happen:
* The `{-# ... #-}` syntax be reserved in particular for compilers (it
largely already is; the Report defines it as "compiler pragma"
syntax). The next Report should also allow implementations to warn in
the case of unrecognized pragmas.
* We introduce a "tool pragma" convention (perhaps even standardized in
the next Report). For this we can follow the model of Liquid Haskell:
`{-@ $TOOL_NAME ... @-}`.
Does this sound sensible?
Cheers,
- Ben
[1] https://github.com/ghc/ghc/pull/204
signature.asc
Description: PGP signature
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
