Re: Treatment of unknown pragmas

Hi! Why not follow the standard in that pragmas were intended for all tools consuming Haskell and not for GHCs exclusive use? All that would require is to make the warning opt-in. Making other tools use a new syntax for the same functionality seems suboptimal to me. Regards, Niklas

24 okt. 2018 kl. 19:38 skrev Ben Gamari :

Neil Mitchell 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