Treatment of unknown pragmas

Jared Weakly jweakly at
Tue Oct 16 18:45:08 UTC 2018

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 <vlad.z.4096 at>

> 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 <ben at> 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]
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list