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-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

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

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 author) now have a whole pile of "how do I disable warnings in Stack", and "what's the equivalent of this in Nix". Personally, it ups the support level significantly that I wouldn't go this route. I think it might be a useful feature in general, as new tools could use the flag to prototype new types of warning, but I imagine once a feature gets popular it becomes too much fuss.

...

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.

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, the list remains pretty short. My guess is the demand is pretty low - we're just whitelisting a handful of additional words that aren't misspellings. Thanks, Neil

...

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.

The extra recompilation is annoying for HLint, true, since you probably don't care about your annotations being visible from other modules, whereas LiquidHaskell does. But I'm surprised by the compilation performance penalty. I would have expected ANN to be fairly cheap. That seems worthy of a bug report, regardless of the current discussion about unknown pragmas.

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 checking. Using it as a compile-time pragma is actually fairly weird from that standpoint.

True. That being said, I wonder if we solve most of these issues by simply type-checking ANNs lazily. That is, just forkM ANNs during typechecking. This would mean that the user wouldn't see an error if the expression contained inside is invalid. On the other hand, the cost of ANNs would decrease significantly and plugins which use them would continue to work unmodified. Strict typechecking behavior could be enabled via a flag. Cheers, - Ben

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 type checker. IIRC HLint’s annotations are already strings, so this wouldn’t be a big deal. What is GHC providing in this case? Parsing the ANN pragmas (not the contents) and attaching them to the relevant Id, which is still a substantial benefit in my opinion. We have some code in LiquidHaskell that does this for local let-binders, and it’s a horrible hack; I’d much rather have GHC do it for us. Sent from my iPhone

On Oct 16, 2018, at 18:00, Ben Gamari wrote:

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 checking. Using it as a compile-time pragma is actually fairly weird from that standpoint.

True. That being said, I wonder if we solve most of these issues by simply type-checking ANNs lazily. That is, just forkM ANNs during typechecking. This would mean that the user wouldn't see an error if the expression contained inside is invalid. On the other hand, the cost of ANNs would decrease significantly and plugins which use them would continue to work unmodified. Strict typechecking behavior could be enabled via a flag.

Cheers,

- Ben

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 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 OPTIONS, CFILES (a Hugs relic), and several more that GHC ignores.

We can either (a) not protect people from mistyped pragmas, or (b) protect people from mistyped pragma names, but then we have to bake in the set of known pragmas

We could choose to have a different convention for pragmas that GHC doesn't know about (as Ben suggests), but then of course we don't get any protection for mistyped pragma names when using that convention.

Cheers Simon

On Tue, 16 Oct 2018 at 21:12, Neil Mitchell wrote:

...

...

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 author) now have a whole pile of "how do I disable warnings in Stack", and "what's the equivalent of this in Nix". Personally, it ups the support level significantly that I wouldn't go this route.

I think it might be a useful feature in general, as new tools could use the flag to prototype new types of warning, but I imagine once a feature gets popular it becomes too much fuss.

...

...

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.

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, the list remains pretty short. My guess is the demand is pretty low - we're just whitelisting a handful of additional words that aren't misspellings.

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

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

-- brandon s allbery kf8nh allbery.b@gmail.com

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 but ghc does. On Tue, Oct 16, 2018 at 6:34 PM Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> 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.

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 #-} 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 OPTIONS, CFILES (a Hugs relic), and several more that GHC ignores.

We can either

(a) not protect people from mistyped pragmas, or

(b) protect people from mistyped pragma names, but then we have to bake in the set of known pragmas

We could choose to have a different convention for pragmas that GHC doesn't know about (as Ben suggests), but then of course we don't get any protection for mistyped pragma names when using that convention.

Cheers

Simon

On Tue, 16 Oct 2018 at 21:12, Neil Mitchell wrote:

...

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 author) now have a whole pile of "how do I disable warnings in Stack", and "what's the equivalent of this in Nix". Personally, it ups the support level significantly that I wouldn't go this route.

I think it might be a useful feature in general, as new tools could use the flag to prototype new types of warning, but I imagine once a feature gets popular it becomes too much fuss.

...

...

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.

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, the list remains pretty short. My guess is the demand is pretty low - we're just whitelisting a handful of additional words that aren't misspellings.

Thanks, Neil _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01%7Csimonpj%40microsoft.com%7Cdb8a204f9dad40d006c208d633a82851%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636753194654711612&sdata=YkmmZJVadGOaWzWtSRQf18D058PdEhj8IiGwF%2B%2BGZFs%3D&reserved=0

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

-- brandon s allbery kf8nh allbery.b@gmail.com

I think Brandon may have misread your example as "{-# HLINT ... #-}". One problem with "{- HLINT" (although I'm personally not in favor of the special-casing) is that if it's just a Haskell comment then it itself is vulnerable to typos. E.g. if I type "{- HILNT foo -}" (L and I swapped), hlint the tool will miss it. Tom

El 16 oct 2018, a las 18:44, Simon Peyton Jones via ghc-devs escribió:

I’m still not getting it. GHC ignores everything between {- and -}. Why would I need to produce 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 ; 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. 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 but ghc does.

On Tue, Oct 16, 2018 at 6:34 PM Simon Peyton Jones via ghc-devs 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.

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 #-} 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 OPTIONS, CFILES (a Hugs relic), and several more that GHC ignores.

We can either (a) not protect people from mistyped pragmas, or (b) protect people from mistyped pragma names, but then we have to bake in the set of known pragmas

We could choose to have a different convention for pragmas that GHC doesn't know about (as Ben suggests), but then of course we don't get any protection for mistyped pragma names when using that convention.

Cheers Simon

On Tue, 16 Oct 2018 at 21:12, Neil Mitchell wrote:

...

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 author) now have a whole pile of "how do I disable warnings in Stack", and "what's the equivalent of this in Nix". Personally, it ups the support level significantly that I wouldn't go this route.

I think it might be a useful feature in general, as new tools could use the flag to prototype new types of warning, but I imagine once a feature gets popular it becomes too much fuss.

...

...

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.

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, the list remains pretty short. My guess is the demand is pretty low - we're just whitelisting a handful of additional words that aren't misspellings.

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

-- brandon s allbery kf8nh allbery.b@gmail.com _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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 pragmas can be lower-case (probably a mistake?) means that {- hlint gets this wrong -} should probably be interpreted as an HLint directive, when it's clearly not intended to be. Note that we can't mandate {-@ or {-! as both are used by Liquid Haskell and Derive respectively to encode non-prefixed information. In my view the three options are: 1) Do nothing. Tell HLint to use {- HLINT -} or find some unencumbered syntax. There's no point mandating a specific unencumbered syntax in the report, as the report already mandates a syntax, namely {-# #-}. 2) Whitelist HLint as a pragma. My preferred solution, but I realise that encoding knowledge of every tool into GHC is not a great solution. 3) Whitelist either X-* or TOOL as a pragma, so GHC has a universal ignored pragma, allowing HLint pragmas to be written as either {-# TOOL HLINT ... #-} or {-# X-HLINT ... #-} Thanks, Neil On Tue, Oct 16, 2018 at 11:44 PM Simon Peyton Jones wrote:

I’m still not getting it. GHC ignores everything between {- and -}. Why would I need to produce 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 ; 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. 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 but ghc does.

On Tue, Oct 16, 2018 at 6:34 PM Simon Peyton Jones via ghc-devs 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.

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 #-} 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 OPTIONS, CFILES (a Hugs relic), and several more that GHC ignores.

We can either

(a) not protect people from mistyped pragmas, or

(b) protect people from mistyped pragma names, but then we have to bake in the set of known pragmas

We could choose to have a different convention for pragmas that GHC doesn't know about (as Ben suggests), but then of course we don't get any protection for mistyped pragma names when using that convention.

Cheers

Simon

On Tue, 16 Oct 2018 at 21:12, Neil Mitchell wrote:

...

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 author) now have a whole pile of "how do I disable warnings in Stack", and "what's the equivalent of this in Nix". Personally, it ups the support level significantly that I wouldn't go this route.

I think it might be a useful feature in general, as new tools could use the flag to prototype new types of warning, but I imagine once a feature gets popular it becomes too much fuss.

...

...

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.

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, the list remains pretty short. My guess is the demand is pretty low - we're just whitelisting a handful of additional words that aren't misspellings.

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

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

--

brandon s allbery kf8nh

allbery.b@gmail.com

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 the others that Neil mentioned. You might say we shouldn't care about mistyped pragma names. If the user accidentally writes {- HLNIT -} and it is silently ignored, that's not our problem. OK, but we cared about it enough for the pragmas that GHC understands to add the special warning, and it's reasonable to expect that HLint users also care about it. (personally I have no stance on whether we should have this warning, there are upsides and downsides. But that's where we are now.) Cheers Simon On 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.

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 #-} 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 OPTIONS, CFILES (a Hugs relic), and several more that GHC ignores.

We can either

(a) not protect people from mistyped pragmas, or

(b) protect people from mistyped pragma names, but then we have to bake in the set of known pragmas

We could choose to have a different convention for pragmas that GHC doesn't know about (as Ben suggests), but then of course we don't get any protection for mistyped pragma names when using that convention.

Cheers

Simon

On Tue, 16 Oct 2018 at 21:12, Neil Mitchell wrote:

...

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 author) now have a whole pile of "how do I disable warnings in Stack", and "what's the equivalent of this in Nix". Personally, it ups the support level significantly that I wouldn't go this route.

I think it might be a useful feature in general, as new tools could use the flag to prototype new types of warning, but I imagine once a feature gets popular it becomes too much fuss.

...

...

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.

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, the list remains pretty short. My guess is the demand is pretty low - we're just whitelisting a handful of additional words that aren't misspellings.

Thanks, Neil _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01%7Csimonpj%40microsoft.com%7Cdb8a204f9dad40d006c208d633a82851%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636753194654711612&sdata=YkmmZJVadGOaWzWtSRQf18D058PdEhj8IiGwF%2B%2BGZFs%3D&reserved=0

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 don't benefit from this. That's one downside, in addition to the others that Neil mentioned.

You might say we shouldn't care about mistyped pragma names. If the user accidentally writes {- HLNIT -} and it is silently ignored, that's not our problem. OK, but we cared about it enough for the pragmas that GHC understands to add the special warning, and it's reasonable to expect that HLint users also care about it.

If this is the case then in my opinion HLint should be the one that checks for mis-spelling.

But there's no way that HLint can know what is a misspelled pragma name. If we look beyond HLint, there is no way that

GHC could know generally what tokens are misspelled pragmas and which are tool names.

Well this is the problem we created by adding -Wunrecognised-pragmas :) Now GHC has to know what all the correctly-spelled pragma names are, and the HLint diff is just following this path. Arguably -Wunrecognised-pragmas is ill-conceived. I'm surprised we didn't have this discussion when it was added (or maybe we did?). But since we have it, it comes with an obligation to have a centralised registry of pragma names, which is currently in GHC. (it doesn't have to be in the source code, of course) 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.

Is this likely to happen? Of course not. However, it is an indication to me that the root cause of this current debate is our lack of a good extensible pragmas. It seems to me that introducing a tool pragma convention, from which tool users can claim namespaces at will, is the right way to fix this.

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. If we decide to do that then fine, it just seems like an inconsistent design. Cheers Simon

Cheers,

- Ben

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 stop me from writing a tool named HLNIT and using those pragmas, but we'll never be able to guard against that. Richard

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 unsustainable.

Why? Making the list 12 elements longer doesn't seem fatal or add any real complexity. And do we have any idea of 12 additional programs that might want settings adding? Maybe we just demand that the program be continuously maintained for over a decade :).

Well, for one this would mean that any packages using these pragmas would be -Werror broken until a new GHC was released. To me this is a sure sign that we need a better story here.

...

Is this likely to happen? Of course not. However, it is an indication to me that the root cause of this current debate is our lack of a good extensible pragmas. It seems to me that introducing a tool pragma convention, from which tool users can claim namespaces at will, is the right way to fix this.

I'd suggest just adding HLINT as a known pragma. But given there isn't any consensus on that, why not add TOOL as a known pragma, and then we've got an extension point which requires only one single entry to the list?

With my GHC hat on this seems acceptable. From a user perspective it has the problem of being quite verbose (and pragma verbosity is already a problem in Haskell, in my opinion). I'll admit, I still don't see the problem with just adopting a variant of standard comment syntax with a convention for tool name prefixes (for instance, the `{-! HLINT ... !-}` suggested earlier). This seems to me to be an all-around better solution: less verbose, easy to parse, and requires no changes to GHC. The downsides seem easily overcome: Editors can be easily modified to give this syntax the same treatment as compiler pragmas. The conflict with Liquid Haskell's syntax is merely temporary as they are moving towards using ANN pragmas anyways. However, even if it weren't a bit of temporary pain seems worthwhile to solve the tool pragma namespacing issue once and for all. However, this is just my opinion as a user. If people want GHC to ignore `{-# TOOL ... #-}` then I certainly won't object. Cheers, - Ben

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 okt. 2018 kl. 19:38 skrev Ben Gamari :

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 unsustainable.

Why? Making the list 12 elements longer doesn't seem fatal or add any real complexity. And do we have any idea of 12 additional programs that might want settings adding? Maybe we just demand that the program be continuously maintained for over a decade :).

Well, for one this would mean that any packages using these pragmas would be -Werror broken until a new GHC was released. To me this is a sure sign that we need a better story here.

...

...

Is this likely to happen? Of course not. However, it is an indication to me that the root cause of this current debate is our lack of a good extensible pragmas. It seems to me that introducing a tool pragma convention, from which tool users can claim namespaces at will, is the right way to fix this.

I'd suggest just adding HLINT as a known pragma. But given there isn't any consensus on that, why not add TOOL as a known pragma, and then we've got an extension point which requires only one single entry to the list?

With my GHC hat on this seems acceptable.

From a user perspective it has the problem of being quite verbose (and pragma verbosity is already a problem in Haskell, in my opinion). I'll admit, I still don't see the problem with just adopting a variant of standard comment syntax with a convention for tool name prefixes (for instance, the `{-! HLINT ... !-}` suggested earlier). This seems to me to be an all-around better solution: less verbose, easy to parse, and requires no changes to GHC.

The downsides seem easily overcome: Editors can be easily modified to give this syntax the same treatment as compiler pragmas. The conflict with Liquid Haskell's syntax is merely temporary as they are moving towards using ANN pragmas anyways. However, even if it weren't a bit of temporary pain seems worthwhile to solve the tool pragma namespacing issue once and for all. However, this is just my opinion as a user.

If people want GHC to ignore `{-# TOOL ... #-}` then I certainly won't object.

Cheers,

- Ben

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

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 2018 at 21:32, Ben Gamari wrote:

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 consider "the compiler" to be something different from tools like HLint.

Of course, on the other hand it also specified that implementations should ignore unknown pragmas, so the original authors clearly didn't anticipate that non-compiler tooling would be so common.

...

... and not for GHCs exclusive use? All that would require is to make the warning opt-in.

Disabling the unknown pragma warning by default would mean that users not be warned if they mis-spelled LANGAGE or INILNE, which could result in frustrating error messages for the uninitiated. It seems to me that we should try to avoid this given just how common these pragmas are in practice.

Finally, in general I think it would be generally useful to have a properly namespaced syntax for tooling pragmas. Afterall, we otherwise end up with tools claiming random bits of syntax, resulting in an unnecessarily steep learning curve and potentially syntactically-colliding tools.

Cheers,

- Ben

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 assumed that all annotations included the LIQUID keyword. Apparently this isn't the case. Thanks for clarifying! Cheers, - Ben [1] https://github.com/ucsd-progsys/liquidhaskell#theorem-proving