Treatment of unknown pragmas

[Brandon Allbery]

Maybe the right answer is to ignore unknown OPTIONS_* pragmas and then use
OPTIONS_HLINT?

On Tue, Oct 16, 2018 at 4:44 PM Simon Marlow <marlowsd at gmail.com> wrote:

> I suggested to Neil that he add the {-# HLINT #-} pragma to GHC. It seemed
> like the least worst option taking into account the various issues that
> have already been described in this thread. I'm OK with adding HLINT; after
> all we already ignore OPTIONS_HADDOCK, OPTIONS_NHC98, a bunch of other
> OPTIONS, CFILES (a Hugs relic), and several more that GHC ignores.
>
> We can either
> (a) not protect people from mistyped pragmas, or
> (b) protect people from mistyped pragma names, but then we have to bake in
> the set of known pragmas
>
> We could choose to have a different convention for pragmas that GHC
> doesn't know about (as Ben suggests), but then of course we don't get any
> protection for mistyped pragma names when using that convention.
>
> Cheers
> Simon
>
>
> On Tue, 16 Oct 2018 at 21:12, Neil Mitchell <ndmitchell at gmail.com> wrote:
>
>> > A warning flag is an interesting way to deal with the issue. On the
>> > other hand, it's not great from an ergonomic perspective; afterall, this
>> > would mean that all users of HLint (and any other tool requiring special
>>
>> Yep, this means every HLint user has to do an extra thing. I (the
>> HLint author) now have a whole pile of "how do I disable warnings in
>> Stack", and "what's the equivalent of this in Nix". Personally, it ups
>> the support level significantly that I wouldn't go this route.
>>
>> I think it might be a useful feature in general, as new tools could
>> use the flag to prototype new types of warning, but I imagine once a
>> feature gets popular it becomes too much fuss.
>>
>> > > I think it makes a lot of sense to have a standard way for
>> third-parties
>> > > to attach string-y information to Haskell source constructs. While
>> it's
>> > > not strictly speaking necessary to standardize the syntax, doing
>> > > so minimizes the chance that tools overlap and hopefully reduces
>> > > the language ecosystem learning curve.
>> >
>> > This sounds exactly like the existing ANN pragma, which is what I've
>> wanted LiquidHaskell to move towards for a long time. What is wrong with
>> using the ANN pragma?
>>
>> Significant compilation performance penalty and extra recompilation.
>> ANN pragmas is what HLint currently uses.
>>
>> >  I'm a bit skeptical of this idea. Afterall, adding cases to the
>> > lexer for every tool that wants a pragma seems quite unsustainable.
>>
>> I don't find this argument that convincing. Given the list already
>> includes CATCH and DERIVE, the bar can't have been _that_ high to
>> entry. And yet, the list remains pretty short. My guess is the demand
>> is pretty low - we're just whitelisting a handful of additional words
>> that aren't misspellings.
>>
>> Thanks, Neil
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allbery.b at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20181016/80ad5224/attachment.html>