Hello Daniel,
Annotations API was discussed earlier in this thread. Main points against are:
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
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
Vladislav Zavialov <vlad.z.4096@gmail.com> 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