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
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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-- brandon s allbery kf8nh allbery.b@gmail.com