Does this need to be *this* hardcoded? Or could we just parse the pragma and
compare it to a list of known pragmas to be parsed from a file (or settings
value?).
The change in question does:
- pragmas = options_pragmas ++ ["cfiles", "contract"]
+ pragmas = options_pragmas ++ ["cfiles", "contract",
"hlint"]
to the `compiler/parser/Lexer.x`, and as such is somewhat hardcoded. So we
already
ignore a bunch of `option_` and those three pragmas.
And I see
<0,option_prags> {
"{-#" { warnThen Opt_WarnUnrecognisedPragmas (text "Unrecognised pragma")
(nested_comment lexToken) }
}
which I believe handles the unrecognisedPragmas case.
Can't we have a ignored-pragmas value in the settings, that just lists all those
we want to ignore, instead of hardcoding them in the Lexer?
That at least feels to me like a less invasive (and easier to adapt) appraoch,
that
might be less controversial? Yes it's just moving goal posts, but it moves the
logic
into a runtime value instead of a compile time value.
Cheers,
Moritz
> On Oct 17, 2018, at 4:05 PM, Simon Marlow <[email protected]> wrote:
>
> Simon - GHC provides some protection against mistyped pragma names, in the
> form of the -Wunrecognised-pragmas warning, but only for {-# ... #-} pragmas.
> If tools decide to use their own pragma syntax, they don't benefit from this.
> That's one downside, in addition to the others that Neil mentioned.
>
> You might say we shouldn't care about mistyped pragma names. If the user
> accidentally writes {- HLNIT -} and it is silently ignored, that's not our
> problem. OK, but we cared about it enough for the pragmas that GHC
> understands to add the special warning, and it's reasonable to expect that
> HLint users also care about it.
>
> (personally I have no stance on whether we should have this warning, there
> are upsides and downsides. But that's where we are now.)
>
> Cheers
> Simon
>
> On Tue, 16 Oct 2018 at 23:34, Simon Peyton Jones <[email protected]>
> wrote:
> I’m still not understanding what’s wrong with
>
>
>
> {- HLINT blah blah -}
>
>
>
> GHC will ignore it. HLint can look at it. Simple.
>
>
>
> I must be missing something obvious.
>
>
>
> Simon
>
>
>
> From: ghc-devs <[email protected]> On Behalf Of Simon Marlow
> Sent: 16 October 2018 21:44
> To: Neil Mitchell <[email protected]>
> Cc: ghc-devs <[email protected]>
> Subject: Re: Treatment of unknown pragmas
>
>
>
> 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 <[email protected]> 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
> [email protected]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> _______________________________________________
> ghc-devs mailing list
> [email protected]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
