<div dir="ltr">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.</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 16, 2018 at 4:29 PM Eric Seidel <<a href="mailto:eric@seidel.io">eric@seidel.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> > 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?<br>
> <br>
> Significant compilation performance penalty and extra recompilation.<br>
> ANN pragmas is what HLint currently uses.<br>
<br>
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. <br>
<br>
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.<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>brandon s allbery kf8nh</div><div><a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a></div></div></div></div></div>