Moritz Angermann <[email protected]> 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
signature.asc
Description: PGP signature
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
