Treatment of unknown pragmas

Tue Oct 16 23:13:08 UTC 2018

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 <amindfv at gmail.com> 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 at 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 <allbery.b at gmail.com>
> *Sent:* 16 October 2018 23:39
> *To:* Simon Peyton Jones <simonpj at microsoft.com>
> *Cc:* Simon Marlow <marlowsd at gmail.com>; Neil Mitchell <
> ndmitchell at gmail.com>; ghc-devs at haskell.org Devs <ghc-devs at haskell.org>
> *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 at 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 <ghc-devs-bounces at haskell.org> *On Behalf Of *Simon
> Marlow
> *Sent:* 16 October 2018 21:44
> *To:* Neil Mitchell <ndmitchell at gmail.com>
> *Cc:* ghc-devs <ghc-devs at haskell.org>
> *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 <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
> <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 at 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 at gmail.com
>
> _______________________________________________
> 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/e7cc9146/attachment.html>