Treatment of unknown pragmas

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Treatment of unknown pragmas

Ben Gamari-2
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Treatment of unknown pragmas

Vladislav Zavialov
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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: Treatment of unknown pragmas

GHC - devs mailing list
In reply to this post by Ben Gamari-2
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 <[hidden email]> On Behalf Of Ben Gamari
| Sent: 16 October 2018 18:51
| To: GHC developers <[hidden email]>; [hidden email]
| 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
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Treatment of unknown pragmas

Jared Weakly
In reply to this post by Vladislav Zavialov
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Treatment of unknown pragmas

Matthew Pickering
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>> [hidden email]
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>> _______________________________________________
>> ghc-devs mailing list
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Treatment of unknown pragmas

Ben Gamari-2
In reply to this post by Vladislav Zavialov
Vladislav Zavialov <[hidden email]> 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

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Treatment of unknown pragmas

Eric Seidel-3
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 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?
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Treatment of unknown pragmas

Neil Mitchell
> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Treatment of unknown pragmas

Boespflug, Mathieu
> >  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.

I agree. GHC presumably gives warnings for most names because most
possible pragma names really are misspellings of what the user
intended to say. Some select few pragma names are likely *not*
misspellings (like CATCH, DERIVE, HLINT, etc), so there the policy is
reversed. Common usage is what tells us is likely a misspelling vs
not. Simply tracking the common usage is the pragmatic choice.
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Treatment of unknown pragmas

Eric Seidel-3
In reply to this post by Neil Mitchell
> > 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.
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Treatment of unknown pragmas

Brandon Allbery
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.

On Tue, Oct 16, 2018 at 4:29 PM Eric Seidel <[hidden email]> wrote:
> > 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.
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


--
brandon s allbery kf8nh

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Treatment of unknown pragmas

Simon Marlow-7
In reply to this post by Neil Mitchell
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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Treatment of unknown pragmas

Brandon Allbery
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


--
brandon s allbery kf8nh

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Treatment of unknown pragmas

Ben Gamari-2
In reply to this post by Eric Seidel-3
Eric Seidel <[hidden email]> 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

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Treatment of unknown pragmas

Ben Gamari-2
In reply to this post by Brandon Allbery
Brandon Allbery <[hidden email]> 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

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Treatment of unknown pragmas

Ben Gamari-2
Ben Gamari <[hidden email]> writes:

> Brandon Allbery <[hidden email]> 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.
>
I suppose the only issue with this idea is that we would also need to
drop them from interface files, lest they would be forced. Perhaps this
is sometimes reasonable, however.


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Treatment of unknown pragmas

Eric Seidel-3
In reply to this post by Ben Gamari-2
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 <[hidden email]> wrote:
>
> Brandon Allbery <[hidden email]> 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

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: Treatment of unknown pragmas

GHC - devs mailing list
In reply to this post by Simon Marlow-7

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 <[hidden email]> On Behalf Of Simon Marlow
Sent: 16 October 2018 21:44
To: Neil Mitchell <[hidden email]>
Cc: ghc-devs <[hidden email]>
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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Treatment of unknown pragmas

Brandon Allbery
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 <[hidden email]> 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 <[hidden email]> On Behalf Of Simon Marlow
Sent: 16 October 2018 21:44
To: Neil Mitchell <[hidden email]>
Cc: ghc-devs <[hidden email]>
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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


--
brandon s allbery kf8nh

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: Treatment of unknown pragmas

GHC - devs mailing list

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 <[hidden email]>
Sent: 16 October 2018 23:39
To: Simon Peyton Jones <[hidden email]>
Cc: Simon Marlow <[hidden email]>; Neil Mitchell <[hidden email]>; [hidden email] Devs <[hidden email]>
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 <[hidden email]> 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 <[hidden email]> On Behalf Of Simon Marlow
Sent: 16 October 2018 21:44
To: Neil Mitchell <[hidden email]>
Cc: ghc-devs <[hidden email]>
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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


 

--

brandon s allbery kf8nh


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
123