<div dir="auto">Was going through <a href="https://downloads.haskell.org/~ghc/7.0.3/docs/html/users_guide/pragmas.html">https://downloads.haskell.org/~ghc/7.0.3/docs/html/users_guide/pragmas.html</a> and came across the SPECIALIZE pragma. Is it possible to write it in a way that it specializes a complete monad transformer stack to given concrete stack?<div dir="auto"><br></div><div dir="auto">-- Saurabh. </div></div><div class="gmail_extra"><br><div class="gmail_quote">On 30 Jan 2017 10:27 am, "Saurabh Nanda" <<a href="mailto:saurabhnanda@gmail.com">saurabhnanda@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Why do you keep expecting the compiler to "be smart"? It's just shuffling data around, any type of magic efficiency with Monadic computations requires specific knowledge about monads, which is not something we encode into the compiler. just saying "this should be obvious" is not very productive.</p></blockquote><div><br></div><div>Two reasons:</div><div><br></div><div>* If inlining certain functions can give a boost to the performance, then is it unreasonable to expect the compiler to have better heuristics about when commonly occurring code patterns should be inlined? In this case monads and mtl being the commonly occurring code patterns.</div><div><br></div><div>* At a broader level, the promise of writing pure functions was to be able to talk about 'intent', not 'implementation' -- the classic `map` vs `for loop` example. Additionally, pure functions give the compiler enough opportunity to optimise code. Both these higher level promises are being broken by this experience. Hence, I'm feeling "cheated"</div><div><br></div><div>-- Saurabh.</div></div>
</div></div>
</blockquote></div></div>