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