Treatment of unknown pragmas

[Niklas Larsson]

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 <ben at smart-cactus.org>:
> 
> Neil Mitchell <ndmitchell at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs