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