Treatment of unknown pragmas

Brandon Allbery allbery.b at gmail.com
Tue Oct 16 20:34:31 UTC 2018


The problem with ANN is it's part of the plugins API, and as such does
things like compiling the expression into the program in case a plugin
generates code using its value, plus things like recompilation checking end
up assuming plugins are in use and doing extra checking. Using it as a
compile-time pragma is actually fairly weird from that standpoint.

On Tue, Oct 16, 2018 at 4:29 PM Eric Seidel <eric at seidel.io> wrote:

> > > 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.
>
> The extra recompilation is annoying for HLint, true, since you probably
> don't care about your annotations being visible from other modules, whereas
> LiquidHaskell does.
>
> But I'm surprised by the compilation performance penalty. I would have
> expected ANN to be fairly cheap. That seems worthy of a bug report,
> regardless of the current discussion about unknown pragmas.
> _______________________________________________
> 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/591865d6/attachment.html>


More information about the ghc-devs mailing list