Treatment of unknown pragmas

[Ben Gamari]

Neil Mitchell <ndmitchell at gmail.com> writes:

> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20181017/0294d372/attachment.sig>