It might be nice if GHC were to actually parse the extensible tool pragmas and
insert them into the AST!
Aesthetically, I prefer the {-# X_HLINT ... #-} syntax over the {-# TOOL HLINT
... #-} syntax, but I don't feel strongly about it.
On Wed, Oct 24, 2018, at 13:38, Ben Gamari wrote:
> Neil Mitchell <ndmitch...@gmail.com> 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
> object.
>
> Cheers,
>
> - Ben
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> Email had 1 attachment:
> + signature.asc
> 1k (application/pgp-signature)
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
