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's clear that we don'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'm not sure how well this can work in practice. Regarding (3), for instance,<br>
it'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'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>