Treatment of unknown pragmas

Ben Gamari ben at
Wed Oct 17 14:08:28 UTC 2018

Moritz Angermann <moritz.angermann at> 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.


- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <>

More information about the ghc-devs mailing list