Re: Treatment of unknown pragmas

Yeh, I'd missed it was a normal comment and not a new pragma. Pretty much every solution has some screw case; sometimes you get to choose between a bunch of "simple, elegant, and wrong" options and have to decide which "and wrong" will be least expensive (or least frustrating). And a problem with normal comments (behind why I'd missed this was one) is I'm not sure they can be as firmly anchored to transformed ASTs; the ANN mechanism at least has that in its favor. Pragmas can as well, as indicated by e.g. {-# UNPACK #-}. Is this 100% true of random comments? And if it is, at what cost to compilations that don't care? I think this needs more than just a SrcSpan, at least for tools like hlint or Liquid Haskell that really want to associate these with AST nodes and maintain them across transformations. On Tue, Oct 16, 2018 at 7:01 PM wrote:

I think Brandon may have misread your example as "{-# HLINT ... #-}".

One problem with "{- HLINT" (although I'm personally not in favor of the special-casing) is that if it's just a Haskell comment then it itself is vulnerable to typos. E.g. if I type "{- HILNT foo -}" (L and I swapped), hlint the tool will miss it.

Tom

El 16 oct 2018, a las 18:44, Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> escribió:

I’m still not getting it. GHC *ignores* everything between {- and -}. Why would I need to produce a new GHC if someone wants to us {- WIMWAM blah -}?

Simon

*From:* Brandon Allbery *Sent:* 16 October 2018 23:39 *To:* Simon Peyton Jones *Cc:* Simon Marlow ; Neil Mitchell < ndmitchell@gmail.com>; ghc-devs@haskell.org Devs *Subject:* Re: Treatment of unknown pragmas

One problem is you have to release a new ghc every time someone comes up with a new pragma-using tool that starts to catch on. Another is that the more of these you have, the more likely a typo will inadvertently match some tool you don't even know about but ghc does.

On Tue, Oct 16, 2018 at 6:34 PM Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> 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 *On Behalf Of *Simon Marlow *Sent:* 16 October 2018 21:44 *To:* Neil Mitchell *Cc:* ghc-devs *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 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01%7Csimonpj%40microsoft.com%7C87133c79a193420d3ebb08d633b833d8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636753263570895397&sdata=zpuwwcwm9abC5oZ8l3V2QsZEdLlKRk%2BZjU1vhLh9Exg%3D&reserved=0

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01%7Csimonpj%40microsoft.com%7C87133c79a193420d3ebb08d633b833d8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636753263570905414&sdata=5Ucs1y3wY%2BfLQign3q7YR2dagE5rBjYU75oHULYqKkQ%3D&reserved=0

--

brandon s allbery kf8nh

allbery.b@gmail.com

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-- brandon s allbery kf8nh allbery.b@gmail.com