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
|

Re: Treatment of unknown pragmas

amindfv
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 <[hidden email]> 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 <[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

_______________________________________________
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
Yeh, I'd missed it was a normal comment and not a new pragma.

Pretty much every solution has some screw case; sometimes you get to choose between a bunch of "simple, elegant, and wrong" options and have to decide which "and wrong" will be least expensive (or least frustrating). And a problem with normal comments (behind why I'd missed this was one) is I'm not sure they can be as firmly anchored to transformed ASTs; the ANN mechanism at least has that in its favor.

Pragmas can as well, as indicated by e.g. {-# UNPACK #-}. Is this 100% true of random comments? And if it is, at what cost to compilations that don't care? I think this needs more than just a SrcSpan, at least for tools like hlint or Liquid Haskell that really want to associate these with AST nodes and maintain them across transformations.

On Tue, Oct 16, 2018 at 7:01 PM <[hidden email]> wrote:
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 <[hidden email]> 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 <[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


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

Neil Mitchell
In reply to this post by GHC - devs mailing list
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
<[hidden email]> 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 <[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
>
> [hidden email]
_______________________________________________
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 GHC - devs mailing list
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 <[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
Reply | Threaded
Open this post in threaded view
|

Re: Treatment of unknown pragmas

Moritz Angermann-2
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?).

The change in question does:


-                    pragmas = options_pragmas ++ ["cfiles", "contract"]
+                    pragmas = options_pragmas ++ ["cfiles", "contract", "hlint"]

to the `compiler/parser/Lexer.x`, and as such is somewhat hardcoded.  So we already
ignore a bunch of `option_` and those three pragmas.

And I see


<0,option_prags> {
 "{-#"  { warnThen Opt_WarnUnrecognisedPragmas (text "Unrecognised pragma")
                   (nested_comment lexToken) }
}

which I believe handles the unrecognisedPragmas case.

Can't we have a ignored-pragmas value in the settings, that just lists all those
we want to ignore, instead of hardcoding them in the Lexer?

That at least feels to me like a less invasive (and easier to adapt) appraoch, that
might be less controversial?  Yes it's just moving goal posts, but it moves the logic
into a runtime value instead of a compile time value.

Cheers,
Moritz

> On Oct 17, 2018, at 4:05 PM, Simon Marlow <[hidden email]> wrote:
>
> 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 <[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


_______________________________________________
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 Simon Marlow-7
Simon Marlow <[hidden email]> 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. If we look beyond HLint, there is no way that
GHC could know generally what tokens are misspelled pragmas and which
are tool names.

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.

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
In reply to this post by Moritz Angermann-2
Moritz Angermann <[hidden email]> 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. In my mind `settings` is something that is
produced and consumed by GHC itself and I don't believe we want to
change that.

> The change in question does:
>
>
> -                    pragmas = options_pragmas ++ ["cfiles", "contract"]
> +                    pragmas = options_pragmas ++ ["cfiles", "contract", "hlint"]
>
> to the `compiler/parser/Lexer.x`, and as such is somewhat hardcoded.  So we already
> ignore a bunch of `option_` and those three pragmas.
>
> And I see
>
>
> <0,option_prags> {
>  "{-#"  { warnThen Opt_WarnUnrecognisedPragmas (text "Unrecognised pragma")
>                    (nested_comment lexToken) }
> }
>
> which I believe handles the unrecognisedPragmas case.
>
> Can't we have a ignored-pragmas value in the settings, that just lists all those
> we want to ignore, instead of hardcoding them in the Lexer?
>
> That at least feels to me like a less invasive (and easier to adapt) appraoch, that
> might be less controversial?  Yes it's just moving goal posts, but it moves the logic
> into a runtime value instead of a compile time value.
>
I don't think it fundamentally changes the problem: another tool would
still be unable to use the same syntax that HLint uses without getting a
patch into GHC. This seems wrong to me.

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
In reply to this post by Neil Mitchell
Neil Mitchell <[hidden email]> 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 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.
>
I agree; having a syntax that can be easily distinguished .

> Note that we can't mandate {-@ or {-! as both are used by Liquid
> Haskell and Derive respectively to encode non-prefixed information.
>
While this clash is unfortunate, I don't consider it to preclude their
usage. Liquid Haskell is currently moving toward using ANN
instead of this special syntax.

I would also suggest that the fact that this conflict exists highlights
the need for a better extensible pragma story.

> 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 ... #-}
>
This is another option that sounds plausible, although the ergonomics is
pretty poor. In general Haskell pragmas are rather long; this would
make this problem worse.

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

Simon Marlow-7
In reply to this post by Ben Gamari-2
On Wed, 17 Oct 2018 at 15:02, Ben Gamari <[hidden email]> wrote:
Simon Marlow <[hidden email]> 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

_______________________________________________
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

Vladislav Zavialov
> 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 arbitrarily named tools out there. Only the user knows
what tools they use, so they must maintain their own whitelist in the
build configuration. That's why we should have -Wunrecognized-pramas
-Wno-pragma=HLINT, -Wno-pragma=LIQUID, ...
On Wed, Oct 17, 2018 at 5:23 PM Simon Marlow <[hidden email]> wrote:

>
> On Wed, 17 Oct 2018 at 15:02, Ben Gamari <[hidden email]> wrote:
>>
>> Simon Marlow <[hidden email]> 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
>
> _______________________________________________
> 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

Richard Eisenberg-4
In reply to this post by Simon Marlow-7


On Oct 17, 2018, at 10:22 AM, Simon Marlow <[hidden email]> 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

_______________________________________________
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

MarLinn
In reply to this post by Eric Seidel-3
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?

As far as I understand it ANN's are not as generally useful as pure pragmas. For example I don't think you can attach an ANN to an import.*

Speaking of imports: would it be a viable idea to define and import pragmas on a source level? What I mean is something like this:

Option A:

-- | In, say, Language.Lint.Pragma: | ------------------------

{-# PRAGMA LINT  LintSetting #-}     -- Tells GHC that the pragma "LINT" exists and optionally adds information for the type checker
{-# PRAGMA HLINT LintSetting #-}     -- Define as many as you want per tool
:
-- | At usage site: | ----------------------------------------

{-# IMPORT Language.Lint.Pragma #-}  -- Could also be more specific, like "USES_TOOL"
:
{-# LINT defaultLintSetting{ … } #-}
:

Option B:

-- | In Language.Lint.Pragma: | ------------------------------

{-# DEFINE LINT :: LintSetting #-}   -- Same as above, different choice of syntax
{-# ALIAS HLINT LINT #-}             -- As long as I'm inventing syntax I might as well go a bit further
:
-- | At usage site: | ----------------------------------------

import Language.Lint.Pragma          -- Pragmas are imported implicitly, just like instances. An import is needed anyway if pragma type ≠ String and/or types are checked
:
{-# LINT defaultLintSetting{ … } #-}
:

Is that too complicated for tool users? Is that easier than {-# OPTIONS_GHC -Wno-pragma=HLINT #-}? Would it make preprocessing harder because imports would have to be parsed first? Could the "import" in option A be implicit if a tool is used via a GHC command line? I don't know enough about either the use of tools nor the implementation of ghc to answer this. But the idea looked like it might be a compromise where tool pragmas could be added outside the ghc source.

Cheers,
MarLinn

PS: * Why would I want to annotate imports? Because many of my experiments aren't bigger than one file. It would be nice if I could make them self-contained and "portable" between development devices. In other words the goal is to embed as much cabal data as possible into my one source file. I can add quite a few things via pragmas and a shebang already, but I haven't found a way to add the list of packages the code depends on in an elegant fashion. What I imagine is that I might annotate groups of imports with the package they come from, similar to what XPackageImports allows. The related project in my ever-growing backlog would be a shim that would extract info like this from annotations and pass it on to cabal. Such a tool probably wouldn't be widely used, so there should be no need to extend GHC for it. But it would be nice to have GHC check spelling and possibly type especially whenever I don't use my as-of-yet non-existent tool.

PPS: It feels like pragmas and Template Haskell might merge into one thing somewhere in the future. Might be worth contemplating that when designing features.


_______________________________________________
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
In reply to this post by Ben Gamari-2
> 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 :).

> 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?

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

Ben Gamari-2
Neil Mitchell <[hidden email]> 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
[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
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 Mitchell <[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)
_______________________________________________
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

Niklas Larsson
In reply to this post by Ben Gamari-2
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 <[hidden email]>:
>
> Neil Mitchell <[hidden email]> 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
> [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
Niklas Larsson <[hidden email]> 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


_______________________________________________
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

Simon Marlow-7
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 <[hidden email]> wrote:
Niklas Larsson <[hidden email]> 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


_______________________________________________
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
Simon Marlow <[hidden email]> 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.
>
In my mind other compilers are of course free to use the {-# ... #-}
syntax has they see fit and GHC has no other choice but to accommodate.
Arguably the report should have just specified that the {-# ... #-}
syntax as namespaced, avoiding this whole situation.

In the case of tools we have the opportunity to correct this mistake
since no strong convention has established itself yet. This is what I am
advocating that we do.

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: [Haskell] Treatment of unknown pragmas

Artem Pelenitsyn
In reply to this post by Ben Gamari-2
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 <[hidden email]> 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 <[hidden email]> wrote:
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
_______________________________________________
_______________________________________________
Haskell mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

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