Treatment of unknown pragmas

Ben Gamari ben at
Wed Oct 24 17:38:27 UTC 2018

Neil Mitchell <ndmitchell at> writes:

>> I'm trying to view the pragma question from the perspective of setting a
>> precedent for other tools. If a dozen Haskell tools were to approach us
>> tomorrow and ask for similar treatment to HLint it's clear that
>> hardcoding pragma lists in the lexer would be unsustainable.
> Why? Making the list 12 elements longer doesn't seem fatal or add any
> real complexity. And do we have any idea of 12 additional programs
> that might want settings adding? Maybe we just demand that the program
> be continuously maintained for over a decade :).
Well, for one this would mean that any packages using these pragmas
would be -Werror broken until a new GHC was released. To me this is a
sure sign that we need a better story here.

>> Is this likely to happen? Of course not. However, it is an indication to
>> me that the root cause of this current debate is our lack of a good
>> extensible pragmas. It seems to me that introducing a tool pragma
>> convention, from which tool users can claim namespaces at will, is the
>> right way to fix this.
> I'd suggest just adding HLINT as a known pragma. But given there isn't
> any consensus on that, why not add TOOL as a known pragma, and then
> we've got an extension point which requires only one single entry to
> the list?
With my GHC hat on this seems acceptable.

From a user perspective it has the problem of being quite verbose (and
pragma verbosity is already a problem in Haskell, in my opinion). I'll
admit, I still don't see the problem with just adopting a variant of
standard comment syntax with a convention for tool name prefixes (for
instance, the `{-! HLINT ... !-}` suggested earlier). This seems to me
to be an all-around better solution: less verbose, easy to parse,
and requires no changes to GHC.

The downsides seem easily overcome: Editors can be easily modified to
give this syntax the same treatment as compiler pragmas. The conflict
with Liquid Haskell's syntax is merely temporary as they are moving
towards using ANN pragmas anyways. However, even if it weren't a bit of
temporary pain seems worthwhile to solve the tool pragma namespacing
issue once and for all. However, this is just my opinion as a user.

If people want GHC to ignore `{-# TOOL ... #-}` then I certainly won't


- 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