Re: [Haskell] Treatment of unknown pragmas

Hello Daniel, Annotations API was discussed earlier in this thread. Main points against are: Neil: Significant compilation performance penalty and extra recompilation. ANN pragmas is what HLint currently uses. Brandon: 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. -- Best, Artem On Sat, 27 Oct 2018 at 22:12 Daniel Wagner wrote:

I don't have a really strong opinion, but... isn't this (attaching string-y data to source constructs) pretty much exactly what GHC's annotation pragma is for? ~d

On Tue, Oct 16, 2018 at 3:14 PM Ben Gamari wrote:

...

Vladislav Zavialov writes:

...

What about introducing -fno-warn-pragma=XXX? People who use HLint will add -fno-warn-pragma=HLINT to their build configuration.

A warning flag is an interesting way to deal with the issue. On the other hand, it's not great from an ergonomic perspective; afterall, this would mean that all users of HLint (and any other tool requiring special pragmas) include this flag in their build configuration. A typical Haskell project already needs too much such boilerplate, in my opinion.

I think it makes a lot of sense to have a standard way for third-parties to attach string-y information to Haskell source constructs. While it's not strictly speaking necessary to standardize the syntax, doing so minimizes the chance that tools overlap and hopefully reduces the language ecosystem learning curve.

Cheers,

- Ben _______________________________________________

Haskell mailing list

...

Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

_______________________________________________ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell