<div dir="ltr">naively, it might really blow up compilation times perhaps? (i'm speculating on the compilation time possibility)<div> Large haskell projects do take a while to build as is, so any changes that can blow up compilation times really merit being thoughtful.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 18, 2013 at 6:20 PM, Andrew Farmer <span dir="ltr"><<a href="mailto:xichekolas@gmail.com" target="_blank">xichekolas@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Maybe this is a good time to ask, since I've always been curious... is there a reason -fexpose-all-unfoldings is not the default? </p>
<p dir="ltr">That is, is there a strong reason to not include the original RHS of *every* exported function in the interface file, regardless of its INLINE/NOINLINE status? This would greatly benefit HERMIT users, for example... or other plugins that do some form of partial evaluation. </p>
<p dir="ltr">I realize interface files would be bigger, but disk is cheap. They would also change more often, maybe triggering more recompilation? Thoughts?</p>
<p dir="ltr">Drew </p><div class="HOEnZb"><div class="h5">
<div class="gmail_quote">On Jul 18, 2013 3:10 PM, "Carter Schonwald" <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@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">So the idea here to make it possible to have a function that can be specialized at certain types, and explicitly inlined at specific use sites, but ghc otherwise will not inline it? Cool!<div><br></div><div>
one thought: might it be simpler to instead have something like EXPLICIT-INLINABLE, rather that requiring the juxtaposition of two pragmas which "seem" contradictory?</div><div><br></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Thu, Jul 18, 2013 at 3:30 PM, Nicolas Frisby <span dir="ltr"><<a href="mailto:nicolas.frisby@gmail.com" target="_blank">nicolas.frisby@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"><div>This table outlines my plan for the compatibility of the pragmas.</div><div><br></div><div>Each cell is formatted as "x/y", where "x" answers "Is the original RHS in the interface file?" and "y" answers "Will GHC try to inline it?".</div>
<div><br></div><div><font face="courier new, monospace"> NOINLINE INLINABLE INLINE<br></font></div><div><span style="font-family:'courier new',monospace"><none> no/no yes/yes yes/enthusiastically</span></div>
<div><span style="font-family:'courier new',monospace"><br></span></div><div><span style="font-family:'courier new',monospace">NOINLINE error yes/no error</span><br></div><div><font face="courier new, monospace">INLINABLE - error error</font></div>
<div><div><font face="courier new, monospace">INLINE - - error</font></div></div><div><br></div><div><font face="arial, helvetica, sans-serif">The proposed new "yes/no" option gives the GHC user more control. It prevents GHC from inlining a function while still supporting the ability to use the annotated function's RHS in another module, via SPECIALISE or the special "inline" function. Moreover, the presence of the RHS in the .hi file could be used by tools other than GHC like plugins or a super-compiler.</font></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote"><div>On Thu, Jul 18, 2013 at 4:20 AM, Simon Peyton-Jones <span dir="ltr"><<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>></span> wrote:<br>
</div><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-GB" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">It seems a little weird, but the internal data types can express it, so if you can make the front end do the right thing I’d be happy
to take it. (Don’t forget the manual.)<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">SImon<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif""> ghc-devs [mailto:<a href="mailto:ghc-devs-bounces@haskell.org" target="_blank">ghc-devs-bounces@haskell.org</a>]
<b>On Behalf Of </b>Nicolas Frisby<br>
<b>Sent:</b> 16 July 2013 21:29<br>
<b>To:</b> <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<b>Subject:</b> Re: defunctionalization<u></u><u></u></span></p>
</div>
</div><div><div>
<p class="MsoNormal"><u></u> <u></u></p>
<p>Ah, I misread that TidyPgm function.It looks like if I build the CoreUnfolding, GHC will respect it. It's just rejecting the pragma combination in HsSyn.<u></u><u></u></p>
<p>On Jul 16, 2013 3:22 PM, "Nicolas Frisby" <<a href="mailto:nicolas.frisby@gmail.com" target="_blank">nicolas.frisby@gmail.com</a>> wrote:<br>
><br>
> I'd like to put a NOINLINE and an INLINABLE pragma on a binding.<br>
><br>
> (I'm sketching a defunctionalization pass. I'd like the 'apply` routine RHS to make it into the interface file, but I do not want it to be inlined, since that'd undo the defunctionalization.)<br>
><br>
> In other words, I'd like a CoreUnfolding value with the uf_guidance = UnfNever.<br>
><br>
> It seems TidyPgm.addExternal ignores such a core unfolding.<br>
><br>
> Would GHC consider a patch to make this work?<br>
><br>
> Thanks.<u></u><u></u></p>
</div></div></div>
</div>
</div>
</blockquote></div></div></div><br></div>
<br>_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
<br></blockquote></div>
</div></div></blockquote></div><br></div>