<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 17, 2013 at 1:27 PM, Dan Burton <span dir="ltr"><<a href="mailto:danburton.email@gmail.com" target="_blank">danburton.email@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I again want to emphasize how we can view INLINE annotations much the same way as type annotations. It is considered good practice to annotate top-level definitions with type signatures. Why? Is it because the compiler can't figure it out? Is it because the programmer doesn't trust the compiler to figure it out? No, it's because it is a visible, enforced sanity check to make sure that the programmer and the compiler are on the same page, regardless of any magic the compiler is capable of. (I like the various ideas that are being thrown around about "asserting" that something will be inlined.)</div>

</blockquote><div><br></div><div>The purpose of top-level signatures is that checking against them will sometimes flag errors in the written code, and to give readers more information about what the code does (similar to documentation). Neither of these is accomplished by INLINE pragmas. The latter would be more like type annotations overriding what the compiler infers, even if they don't unify.<br>

</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I see superfluous INLINE pragmas as for the benefit of humans, allowing them to express their desires explicitly, rather than relying on implicit behavior that is hard for the average muggle to understand, verify, or guarantee. If someone reads through the source, and wonders whether "bool" will be inlined, they don't need to know any details about the current state of the inliner algorithm when they can just see the pragma right there in the source.</div>

</div></blockquote><div><br></div><div>Frankly, no one should have to worry about whether bool should be inlined. It should just be fast. It's pretty abysmal* in general that so many high-performance libraries need** INLINE all over the place like they do. I'm the author of one (vector-algorithms), and I don't like it. I don't know how to fix GHC for my case (which, by the way, is very different from bool), but I one day hope to remove all the INLINEs from it. They are a terrible way of achieving what they accomplish, but it's order(s) of magnitude in performance. <br>

<br></div><div>Many detractors of types like to say that their purpose is just to aid the compiler in optimization. That's wrong, but INLINE pragmas and the like are exactly that, and if they are often on people's minds, it's because the compiler is not yet smart enough. I don't think this is a state of affairs we should accept or encourage by putting redundant pragmas on everything. It's exactly the kind of micro-optimization that I don't want to have to think about in a language like Haskell. But unfortunately, GHC probably requires more worrying about this (for performance use cases) than modern C compilers.<br>
<br></div><div>Constantly giving hints to the compiler about basic inlining for acceptable performance is not being "the master." It is being the assistant.<br></div><div>
<br></div><div>-- Dan<br><br></div><div>[*] No offense to the GHC devs. They do a great job, and I personally don't know how to do this better.<br><br></div><div>[**] This is assuming that many of the libraries actually need the pragmas. I expect a lot of the INLINEs in lens are the result of Ed just mechanically putting them on everything. And many INLINEs you see in base (mentioned earlier) may well be from code that was written during poorer inlining heuristics, but hasn't been revised with that regard.<br>

</div></div></div></div>