Re: Treatment of unknown pragmas

I like the suggestion of a flag. For any realistic compilation you have to pass a large number of flags to GHC anyway. `stack`, `cabal` or so on can choose to pass the additional flag by default if they wish or make it more ergonomic to do so. On Tue, Oct 16, 2018 at 7:58 PM Jared Weakly wrote:

The main problem I see with this is now N tools need to implement support for that flag and it will need to be configured for every tool separately. If we standardize on a tool pragma in the compiler, all that stays automatic as it is now (a huge plus for tooling, which should as beginner friendly as possible). It also, in my eyes, helps enforce a cleaner distinction between pragmas as a feature-gate and pragmas as a compiler/tooling directive

On Tue, Oct 16, 2018, 11:13 AM Vladislav Zavialov wrote:

...

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

On Tue, Oct 16, 2018, 20:51 Ben Gamari wrote:

...

Hi everyone,

Recently Neil Mitchell opened a pull request [1] proposing a single-line change: Adding `{-# HLINT ... #-}` to the list of pragmas ignored by the lexer. I'm a bit skeptical of this idea. Afterall, adding cases to the lexer for every tool that wants a pragma seems quite unsustainable.

On the other hand, a reasonable counter-argument could be made on the basis of the Haskell Report, which specifically says that implementations should ignore unrecognized pragmas. If GHC did this (instead of warning, as it now does) then this wouldn't be a problem.

Of course, silently ignoring mis-typed pragmas sounds terrible from a usability perspective. For this reason I proposed that the following happen:

* The `{-# ... #-}` syntax be reserved in particular for compilers (it largely already is; the Report defines it as "compiler pragma" syntax). The next Report should also allow implementations to warn in the case of unrecognized pragmas.

* We introduce a "tool pragma" convention (perhaps even standardized in the next Report). For this we can follow the model of Liquid Haskell: `{-@ $TOOL_NAME ... @-}`.

Does this sound sensible?

Cheers,

- Ben

[1] https://github.com/ghc/ghc/pull/204 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

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