<div dir="ltr"><div>Hello Daniel,</div><div><br></div><div>Annotations API was discussed earlier in this thread. Main points again<span class="inbox-inbox-gr_ inbox-inbox-gr_54 inbox-inbox-gr-alert inbox-inbox-gr_spell inbox-inbox-gr_inline_cards inbox-inbox-gr_run_anim inbox-inbox-ContextualSpelling inbox-inbox-ins-del inbox-inbox-multiReplace" id="inbox-inbox-54">s</span>t are:</div><div><br></div><div><div class="inbox-inbox-uyb8Gf"><div><div class="inbox-inbox-pv">Neil:<br></div></div></div><div class="inbox-inbox-uyb8Gf"><div><div class="inbox-inbox-F3hlO">Significant compilation performance penalty and extra recompilation. ANN <span class="inbox-inbox-lG">pragmas</span> is what HLint currently uses.</div></div></div></div><div><br></div><div>Brandon:</div><div>The problem with ANN is it's part <span class="inbox-inbox-lG">of</span> 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><div><br></div><div>--</div><div>Best, Artem<br></div><div><div class="gmail_quote"><div dir="ltr">On Sat, 27 Oct 2018 at 22:12 Daniel Wagner <<a href="mailto:dmwit@dmwit.com">dmwit@dmwit.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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?<div>~d</div></div><br><div class="gmail_quote"></div><div class="gmail_quote"><div dir="ltr">On Tue, Oct 16, 2018 at 3:14 PM Ben Gamari <<a href="mailto:ben@smart-cactus.org" target="_blank">ben@smart-cactus.org</a>> wrote:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Vladislav Zavialov <<a href="mailto:vlad.z.4096@gmail.com" target="_blank">vlad.z.4096@gmail.com</a>> writes:<br>
<br>
> What about introducing -fno-warn-pragma=XXX? People who use HLint will<br>
> add -fno-warn-pragma=HLINT to their build configuration.<br>
><br>
A warning flag is an interesting way to deal with the issue. On the<br>
other hand, it's not great from an ergonomic perspective; afterall, this<br>
would mean that all users of HLint (and any other tool requiring special<br>
pragmas) include this flag in their build configuration. A typical<br>
Haskell project already needs too much such boilerplate, in my opinion.<br>
<br>
I think it makes a lot of sense to have a standard way for third-parties<br>
to attach string-y information to Haskell source constructs. While it's<br>
not strictly speaking necessary to standardize the syntax, doing<br>
so minimizes the chance that tools overlap and hopefully reduces<br>
the language ecosystem learning curve.<br>
<br>
Cheers,<br>
<br>
- Ben<br>
_______________________________________________<br></blockquote></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Haskell mailing list<br>
<a href="mailto:Haskell@haskell.org" target="_blank">Haskell@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell</a><br>
</blockquote></div>
_______________________________________________<br>
Haskell mailing list<br>
<a href="mailto:Haskell@haskell.org" target="_blank">Haskell@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell</a><br>
</blockquote></div></div></div>