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
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
Simon Marlow writes:
> What pragma syntax should other Haskell compilers use? I don't think it's
> fair for GHC to have exclusive rights to the pragma syntax form the report,
> and other compilers should not be relegated to using {-# X-FOOHC ... #-}.
> But now we have all the same issues again.
What pragma syntax should other Haskell compilers use? I don't think it's
fair for GHC to have exclusive rights to the pragma syntax form the report,
and other compilers should not be relegated to using {-# X-FOOHC ... #-}.
But now we have all the same issues again.
Cheers
Simon
On Thu, 25 Oct
Niklas Larsson writes:
> Hi!
>
> Why not follow the standard in that pragmas were intended for all
> tools consuming Haskell ...
That much isn't clear to me. The Report defines the syntax very
specifically to be for "compiler pragmas" to be used by "compiler
implementations". I personally
Hi!
Why not follow the standard in that pragmas were intended for all tools
consuming Haskell and not for GHCs exclusive use? All that would require is to
make the warning opt-in.
Making other tools use a new syntax for the same functionality seems suboptimal
to me.
Regards,
Niklas
> 24
It might be nice if GHC were to actually parse the extensible tool pragmas and
insert them into the AST!
Aesthetically, I prefer the {-# X_HLINT ... #-} syntax over the {-# TOOL HLINT
... #-} syntax, but I don't feel strongly about it.
On Wed, Oct 24, 2018, at 13:38, Ben Gamari wrote:
> Neil
Neil Mitchell writes:
>> I'm trying to view the pragma question from the perspective of setting a
>> precedent for other tools. If a dozen Haskell tools were to approach us
>> tomorrow and ask for similar treatment to HLint it's clear that
>> hardcoding pragma lists in the lexer would be
> I'm trying to view the pragma question from the perspective of setting a
> precedent for other tools. If a dozen Haskell tools were to approach us
> tomorrow and ask for similar treatment to HLint it's clear that
> hardcoding pragma lists in the lexer would be unsustainable.
Why? Making the
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
> On Oct 17, 2018, at 10:22 AM, Simon Marlow wrote:
>
> but then nothing wil notice if you say {-# TOOL HLNIT ... #-} by mistak
This seems fixable. Any tool can slurp in all `TOOL` (or `X-`, which I prefer)
pragmas and look for ones that appear to be misspellings. Of course, this
doesn't
> And sacrifice checking for misspelled pragma names in those namespaces? Sure
> we can say {-# TOOL FOO .. #-} is ignored by GHC, but then nothing wil notice
> if you say {-# TOOL HLNIT ... #-} by mistake.
Yes! But we can't have the whitelist of pragmas hardcoded in GHC, as
there may be
On Wed, 17 Oct 2018 at 15:02, Ben Gamari wrote:
> Simon Marlow writes:
>
> > Simon - GHC provides some protection against mistyped pragma names, in
> the
> > form of the -Wunrecognised-pragmas warning, but only for {-# ... #-}
> > pragmas. If tools decide to use their own pragma syntax, they
Neil Mitchell writes:
> People expect pragmas that are machine readable to use the pragma
> syntax, and the Haskell report suggests that is the right thing to
> expect. They can be highlighted intelligently by IDEs, are immune from
> accidental mix ups with normal comments etc. The fact that
Moritz Angermann writes:
> Does this need to be *this* hardcoded? Or could we just parse the pragma and
> compare it to a list of known pragmas to be parsed from a file (or settings
> value?).
>
To be clear, I don't think we want to start considering `settings` to be
a user configuration file.
Simon Marlow writes:
> Simon - GHC provides some protection against mistyped pragma names, in the
> form of the -Wunrecognised-pragmas warning, but only for {-# ... #-}
> pragmas. If tools decide to use their own pragma syntax, they don't benefit
> from this. That's one downside, in addition to
n Tue, 16 Oct 2018 at 23:34, Simon Peyton Jones
> 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.
&g
; {- HLINT blah blah -}
>
>
>
> GHC will ignore it. HLint can look at it. Simple.
>
>
>
> I must be missing something obvious.
>
>
>
> Simon
>
>
>
> *From:* ghc-devs *On Behalf Of *Simon
> Marlow
> *Sent:* 16 October 2018 21:44
> *To:
Simon Peyton Jones
> Cc: Simon Marlow ; Neil Mitchell ;
> ghc-devs@haskell.org Devs
> Subject: Re: Treatment of unknown pragmas
>
>
>
> 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. Anothe
roduce a new GHC if someone wants to us {- WIMWAM
> blah -}?
>
>
>
> Simon
>
>
>
> *From:* Brandon Allbery
> *Sent:* 16 October 2018 23:39
> *To:* Simon Peyton Jones
> *Cc:* Simon Marlow ; Neil Mitchell <
> ndmitch...@gmail.com>; ghc-devs@haskell.org Devs
>
MWAM blah -}?
>
> Simon
>
> From: Brandon Allbery
> Sent: 16 October 2018 23:39
> To: Simon Peyton Jones
> Cc: Simon Marlow ; Neil Mitchell ;
> ghc-devs@haskell.org Devs
> Subject: Re: Treatment of unknown pragmas
>
> One problem is you have to release a n
Subject: Re: Treatment of unknown pragmas
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
vious.
>
>
>
> Simon
>
>
>
> *From:* ghc-devs *On Behalf Of *Simon
> Marlow
> *Sent:* 16 October 2018 21:44
> *To:* Neil Mitchell
> *Cc:* ghc-devs
> *Subject:* Re: Treatment of unknown pragmas
>
>
>
> I suggested to Neil that he add the {-# HLINT #
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
Another option could be to introduce a lighter ANN that doesn’t actually embed
anything into the module, instead just making the annotations available to
plugins and API users during compilation of that particular module. It could
also be restricted to string annotations to avoid invoking the
Ben Gamari writes:
> Brandon Allbery writes:
>
>> 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
Brandon Allbery writes:
> 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
Eric Seidel writes:
> On Tue, Oct 16, 2018, at 15:14, Ben Gamari wrote:
>
>> For this we can follow the model of Liquid Haskell: `{-@ $TOOL_NAME ... @-}`
>
> LiquidHaskell does not use `{-@ LIQUID ... @-}`, we just write the
> annotation inside `{-@ ... @-}` :)
>
Ahh, I see. I saw [1] and
Maybe the right answer is to ignore unknown OPTIONS_* pragmas and then use
OPTIONS_HLINT?
On Tue, Oct 16, 2018 at 4:44 PM Simon Marlow wrote:
> 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
>
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
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
> > 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,
> 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
On Tue, Oct 16, 2018, at 15:14, Ben Gamari wrote:
> For this we can follow the model of Liquid Haskell: `{-@ $TOOL_NAME ... @-}`
LiquidHaskell does not use `{-@ LIQUID ... @-}`, we just write the annotation
inside `{-@ ... @-}` :)
> I think it makes a lot of sense to have a standard way for
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,
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
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
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.
40 matches
Mail list logo
