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's nice to write generic code over numeric types (Double, Float), but if it doesn'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'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't possible.<div>
<br></div><div>Of course, I have no idea what the ramifications of this would be; I just thought I'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"><<a href="mailto:jpm@cs.uu.nl" target="_blank">jpm@cs.uu.nl</a>></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'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>
<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>