Neil Mitchell <ndmitch...@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
signature.asc
Description: PGP signature
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
