On a related note, it would be nice to have a little more tooling for ensuring that SPECIALIZE pragmas take full effect.  In particular, it&#39;s nice to write generic code over numeric types (Double, Float), but if it doesn&#39;t get specialized away, performance really tanks.  Going through a codebase and manually annotating all uses of the class can be really laborious, and it&#39;s a brittle solution.  It would be nice to indicate to the compiler that a particular instance or even a particular class should always be specialized away, and to get some warnings when this isn&#39;t possible.<div>
<br></div><div>Of course, I have no idea what the ramifications of this would be; I just thought I&#39;d file the idea under this thread.</div><div><br></div><div><br></div><div>Ryan<br><br><div class="gmail_quote">On Thu, Oct 25, 2012 at 9:56 AM, José Pedro Magalhães <span dir="ltr">&lt;<a href="mailto:jpm@cs.uu.nl" target="_blank">jpm@cs.uu.nl</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br><br>Following up on a chat with Simon Peyton Jones at ICFP, I would like to discuss the<br>possible introduction of a EPHEMERAL pragma. For example:<br>
<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">

{-# EPHEMERAL Rep #-}<br>data Rep = ...<br></blockquote><br>This pragma would indicate that the programmer intends the Rep datatype not to<br>be present in the final generated core code. Its proposed semantics are the following:<br>


<br>1. Make the compiler very keen to inline any functions that produce or consume Rep.<br><br>2. If Rep is exported, make all functions that operate on Rep INLINABLE (that is, make<br>their code available for inlining in other modules).<br>


<br>3. Emit a warning if the generated core code still contains uses of Rep.<br><br>My main use case for such a pragma is in the generic representation of datatypes in<br>GHC.Generics. It&#39;s clear that we don&#39;t want sums and products lying around in user<br>


code, and in most cases we can get rid of them by inlining aggressively. Hopefully<br>such a pragma can simplify or entirely replace the use of INLINE/INLINABLE pragmas<br>in some cases.<br><br>However, I&#39;m not sure how well this can work in practice. Regarding (3), for instance,<br>


it&#39;s clear that functions that operate on Rep will be around in the final core code;<br>perhaps only functions which do not directly produce or consume Rep, yet end up<br>having values of Rep within them, should trigger a warning.<br>


<br>(1) is hard to do well, in general. In particular when there are rewriting rules involving<br>values of Rep, or functions that produce/consume Rep, the order in which they are<br>inlined might affect the elimination of Rep values.<br>


<br>In any case, I thought I&#39;d share this with this list, in the hope to get feedback regarding<br>how to improve the inliner (and the feedback programmers get regarding inlining).<br><br><br>Cheers,<br>Pedro<br><br>


<br>_______________________________________________<br>
Glasgow-haskell-users mailing list<br>
<a href="mailto:Glasgow-haskell-users@haskell.org">Glasgow-haskell-users@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/glasgow-haskell-users" target="_blank">http://www.haskell.org/mailman/listinfo/glasgow-haskell-users</a><br>
<br></blockquote></div><br></div>