Neil Mitchell
People expect pragmas that are machine readable to use the pragma syntax, and the Haskell report suggests that is the right thing to expect. They can be highlighted intelligently by IDEs, are immune from accidental mix ups with normal comments etc. The fact that pragmas can be lower-case (probably a mistake?) means that {- hlint gets this wrong -} should probably be interpreted as an HLint directive, when it's clearly not intended to be.
I agree; having a syntax that can be easily distinguished .
Note that we can't mandate {-@ or {-! as both are used by Liquid Haskell and Derive respectively to encode non-prefixed information.
While this clash is unfortunate, I don't consider it to preclude their usage. Liquid Haskell is currently moving toward using ANN instead of this special syntax. I would also suggest that the fact that this conflict exists highlights the need for a better extensible pragma story.
In my view the three options are:
1) Do nothing. Tell HLint to use {- HLINT -} or find some unencumbered syntax. There's no point mandating a specific unencumbered syntax in the report, as the report already mandates a syntax, namely {-# #-}.
2) Whitelist HLint as a pragma. My preferred solution, but I realise that encoding knowledge of every tool into GHC is not a great solution.
3) Whitelist either X-* or TOOL as a pragma, so GHC has a universal ignored pragma, allowing HLint pragmas to be written as either {-# TOOL HLINT ... #-} or {-# X-HLINT ... #-}
This is another option that sounds plausible, although the ergonomics is pretty poor. In general Haskell pragmas are rather long; this would make this problem worse. Cheers, - Ben