[Haskell] Treatment of unknown pragmas

[Ben Gamari]

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

[Simon Peyton Jones via Haskell]

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 <ghc-devs-***@haskell.org> On Behalf Of Ben Gamari
| Sent: 16 October 2018 18:51
| To: GHC developers <ghc-***@haskell.org>; ***@haskell.org
| Subject: Treatment of unknown pragmas
| Hi everyone,
|
| Recently Neil Mitchell opened a pull request [1] proposing a single-line
| change: Adding `{-# HLINT ... #-}` to the list of pragmas ignored by the
| lexer. I'm a bit skeptical of this idea. Afterall, adding cases to the
| lexer for every tool that wants a pragma seems quite unsustainable.
|
| On the other hand, a reasonable counter-argument could be made on the
| basis of the Haskell Report, which specifically says that
| implementations should ignore unrecognized pragmas. If GHC did this
| (instead of warning, as it now does) then this wouldn't be a problem.
|
| Of course, silently ignoring mis-typed pragmas sounds terrible from a
| usability perspective. For this reason I proposed that the following
| happen:
|
| * The `{-# ... #-}` syntax be reserved in particular for compilers (it
| largely already is; the Report defines it as "compiler pragma"
| syntax). The next Report should also allow implementations to warn in
| the case of unrecognized pragmas.
|
| * We introduce a "tool pragma" convention (perhaps even standardized in
| the next Report). For this we can follow the model of Liquid Haskell:
| `{-@ $TOOL_NAME ... @-}`.
|
| Does this sound sensible?
|
| Cheers,
|
| - Ben
|
|
| [1] https://github.com/ghc/ghc/pull/204

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

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

What about introducing -fno-warn-pragma=XXX? People who use HLint will add -fno-warn-pragma=HLINT to their build configuration.

Post by Ben Gamari
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
* 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
Does this sound sensible?
Cheers,
- Ben
[1] https://github.com/ghc/ghc/pull/204
_______________________________________________
ghc-devs mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

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

[Ben Gamari]

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

[Daniel Wagner]

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

Post by Ben Gamari

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

[Artem Pelenitsyn]

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

Post by Daniel Wagner
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

Post by Ben Gamari

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

Post by Ben Gamari
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

_______________________________________________
Haskell mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell