<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p
        {mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0cm;
        mso-margin-bottom-alt:auto;
        margin-left:0cm;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
p.Code, li.Code, div.Code
        {mso-style-name:Code;
        mso-style-link:"Code Char";
        margin-top:0cm;
        margin-right:0cm;
        margin-bottom:0cm;
        margin-left:36.0pt;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Courier New";
        color:#1F497D;}
span.CodeChar
        {mso-style-name:"Code Char";
        mso-style-link:Code;
        font-family:"Courier New";
        color:#1F497D;}
span.EmailStyle20
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri","sans-serif";
        mso-fareast-language:EN-US;}
.MsoPapDefault
        {mso-style-type:export-only;
        margin-top:6.0pt;
        margin-right:0cm;
        margin-bottom:6.0pt;
        margin-left:0cm;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US">Actually the CONLIKE thing still allows them to float, but makes RULES continue to work even though they’ve been floated.   See the
 user manual.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></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""> Dan Doel [mailto:dan.doel@gmail.com]
<br>
<b>Sent:</b> 28 August 2014 16:48<br>
<b>To:</b> Simon Peyton Jones<br>
<b>Cc:</b> John Lato; David Feuer; ghc-devs<br>
<b>Subject:</b> Re: Why isn't ($) inlining when I want?<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:12.0pt;margin-left:0cm">
<span style="font-family:"Arial","sans-serif"">Okay, so marking things as conlike will make GHC avoid floating them?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="font-family:"Arial","sans-serif"">I'm pretty sure that in most vector cases, this is a straight pessimization. There is no way to avoid the extra allocation of integers, because most intermediate vector types are unboxed, so the integer allocation
 will be performed regardless. Only boxed vectors might be an exception.<o:p></o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:12.0pt;margin-left:0cm">
<o:p> </o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
On Thu, Aug 28, 2014 at 4:14 AM, Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif";color:#1F497D">I remember doing some work on the “floating of constant lists” question.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif";color:#1F497D">First, [1..n] turns into (enumFromTo 1 n), and if enumFromTo was expensive, then sharing it might be a good plan. 
 So GHC would have to know that it was cheap.  </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif";color:#1F497D">I did experiment with “cheapBuild” see
<a href="https://ghc.haskell.org/trac/ghc/ticket/7206" target="_blank">https://ghc.haskell.org/trac/ghc/ticket/7206</a>, but as you’ll see there, the results were equivocal.  By duplicating the [1..n] we were allocating two copies of (I# 4), (I# 5) etc, and
 that increased allocation and GC time.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif";color:#1F497D">So it’s unclear, in general, whether in these examples it is better to share the [1..n] between all calls of ‘loop’,
 or to duplicate it.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif";color:#1F497D">All that said, Dan’s question of why X fuses and very-similar Y doesn’t was a surprise to me; I’ll look into that.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif";color:#1F497D"><br>
Simon</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></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" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><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"">
 John Lato [mailto:<a href="mailto:jwlato@gmail.com" target="_blank">jwlato@gmail.com</a>]
<br>
<b>Sent:</b> 28 August 2014 00:17<br>
<b>To:</b> Dan Doel<br>
<b>Cc:</b> Simon Peyton Jones; David Feuer; ghc-devs</span><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><br>
<b>Subject:</b> Re: Why isn't ($) inlining when I want?<o:p></o:p></p>
</div>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">I sometimes think the solution is to make let-floating apply in fewer cases.  I'm not sure we ever want to float out intermediate lists, the cost of creating them is very small relative
 to the memory consumption if they do happen to get shared.<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">My approach is typically to mark loop INLINE.  This very often results in the code I want (with vector, which I use more than lists), but it is a big hammer to apply.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">John<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">On Thu, Aug 28, 2014 at 5:56 AM, Dan Doel <<a href="mailto:dan.doel@gmail.com" target="_blank">dan.doel@gmail.com</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><span style="font-family:"Arial","sans-serif"">I think talking about inlining of $ may not be addressing the crux of the problem here.<br>
<br>
The issue seems to be about functions like the one in the first message. For instance:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"><span style="font-family:"Arial","sans-serif"">    loop :: (Int -> Int) -> Int</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><span style="font-family:"Arial","sans-serif"">    loop g = sum . map g $ [1..1000000]</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><span style="font-family:"Arial","sans-serif"">Suppose for argument that we have a fusion framework that would handle this. The problem is that this does not actually turn into a loop
 over integers, because the constant [1..1000000] gets floated out. It instead builds a list/vector/whatever.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><span style="font-family:"Arial","sans-serif"">By contrast, if we write:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"><span style="font-family:"Arial","sans-serif"">    loop' :: Int</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><span style="font-family:"Arial","sans-serif"">    loop' = sum . map (+1) $ [1..1000000]</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><span style="font-family:"Arial","sans-serif"">this does turn into a loop over integers, with no intermediate list. Presumably this is due to there being no work to be saved ever by floating
 the list out. These are the examples people usually test fusion with.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><span style="font-family:"Arial","sans-serif"">And if loop is small enough to inline, it turns out that the actual code that gets run will be the same as loop', because everything will
 get inlined and fused. But it is also possible to make loop big enough to not inline, and then the floating will pessimize the overall code.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><span style="font-family:"Arial","sans-serif"">So the core issue is that constant floating blocks some fusion opportunities. It is trying to save the work of building the structure more
 than once, but fusion can cause the structure to not be built at all. And the floating happens before fusion can reasonably be expected to work.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><span style="font-family:"Arial","sans-serif"">Can anything be done about this?</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><span style="font-family:"Arial","sans-serif"">I've verified that this kind of situation also affects vector. And it seems to be an issue even if loop is written:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><span style="font-family:"Arial","sans-serif"">    loop g = sum (map g [1..1000000])</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"><span style="font-family:"Arial","sans-serif";color:#888888">-- Dan</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">On Wed, Aug 27, 2014 at 3:38 PM, Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">You'll have to do more detective work! In your dump I see "Inactive unfolding $".  So that's why it's not being inlined.  That message comes from CoreUnfold, line 941 or so.  The Boolean
 active_unfolding is passed in to callSiteInline from Simplify, line 1408 or so.  It is generated by the function activeUnfolding, defined in SimplUtils.<br>
<br>
But you have probably change the "CompilerPhase" data type, so I can't guess what is happening.  But if you just follow it through I'm sure you'll find it.<br>
<span style="color:#888888"><br>
Simon</span><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"><br>
| -----Original Message-----<br>
| From: David Feuer [mailto:<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>]<br>
| Sent: 27 August 2014 17:22<br>
| To: Simon Peyton Jones<br>
| Cc: ghc-devs<br>
| Subject: Re: Why isn't ($) inlining when I want?<br>
|<br>
| I just ran that (results attached), and as far as I can tell, it<br>
| doesn't even *consider* inlining ($) until phase 2.<br>
|<br>
| On Wed, Aug 27, 2014 at 4:03 AM, Simon Peyton Jones<br>
| <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>> wrote:<br>
| > It's hard to tell since you are using a modified compiler.  Try running<br>
| with -ddump-occur-anal -dverbose-core2core -ddump-inlinings.  That will<br>
| show you every inlining, whether failed or successful. You can see the<br>
| attempt to inline ($) and there is some info with the output that may<br>
| help to explain why it did or did not work.<br>
| ><br>
| > Try that<br>
| ><br>
| > Simon<br>
| ><br>
| > | -----Original Message-----<br>
| > | From: ghc-devs [mailto:<a href="mailto:ghc-devs-bounces@haskell.org" target="_blank">ghc-devs-bounces@haskell.org</a>] On Behalf Of<br>
| David<br>
| > | Feuer<br>
| > | Sent: 27 August 2014 04:50<br>
| > | To: ghc-devs; Carter Schonwald<br>
| > | Subject: Why isn't ($) inlining when I want?<br>
| > |<br>
| > | tl;dr  I added a simplifier run with inlining enabled between<br>
| > | specialization and floating out. It seems incapable of inlining<br>
| > | saturated applications of ($), and I can't figure out why. These are<br>
| > | inlined later, when phase 2 runs. Am I running the simplifier wrong<br>
| or<br>
| > | something?<br>
| > |<br>
| > |<br>
| > | I'm working on this simple little fusion pipeline:<br>
| > |<br>
| > | {-# INLINE takeWhile #-}<br>
| > | takeWhile p xs = build builder<br>
| > |   where<br>
| > |     builder c n = foldr go n xs<br>
| > |       where<br>
| > |         go x r = if p x then x `c` r else n<br>
| > |<br>
| > | foo c n x = foldr c n . takeWhile (/= (1::Int)) $ [-9..10]<br>
| > |<br>
| > | There are some issues with the enumFrom definition that break things.<br>
| > | If I use a fusible unfoldr that produces some numbers instead, that<br>
| > | issue goes away. Part of that problem (but not all of it) is that the<br>
| > | simplifier doesn't run to apply rules between specialization and full<br>
| > | laziness, so there's no opportunity for the specialization of<br>
| > | enumFromTo to Int to trigger the rewrite to a build form and fusion<br>
| > | with foldr before full laziness tears things apart. The other problem<br>
| > | is that inlining doesn't happen at all before full laziness, so<br>
| things<br>
| > | defined using foldr and/or build aren't actually exposed as such<br>
| until<br>
| > | afterwards. Therefore I decided to try adding a simplifier run with<br>
| > | inlining between specialization and floating out:<br>
| > |<br>
| > |         runWhen do_specialise CoreDoSpecialising,<br>
| > |<br>
| > |         runWhen full_laziness $ CoreDoSimplify max_iter<br>
| > |                        (base_mode { sm_phase = InitialPhase<br>
| > |                                   , sm_names = ["PostGentle"]<br>
| > |                                   , sm_rules = rules_on<br>
| > |                                   , sm_inline = True<br>
| > |                                   , sm_case_case = False }),<br>
| > |<br>
| > |         runWhen full_laziness $<br>
| > |            CoreDoFloatOutwards FloatOutSwitches {<br>
| > |                                  floatOutLambdas   = Just 0,<br>
| > |                                  floatOutConstants = True,<br>
| > |                                  floatOutPartialApplications = False<br>
| },<br>
| > |<br>
| > | The weird thing is that for some reason this doesn't inline ($), even<br>
| > | though it appears to be saturated. Using the modified thing with (my<br>
| > | version of) unfoldr:<br>
| > |<br>
| > | foo c n x = (foldr c n . takeWhile (/= (1::Int))) $ unfoldr (potato<br>
| 10)<br>
| > | (-9)<br>
| > |<br>
| > | potato :: Int -> Int -> Maybe (Int, Int)<br>
| > | potato n m | m <= n = Just (m, m)<br>
| > |            | otherwise = Nothing<br>
| > |<br>
| > |<br>
| > | I get this out of the specializer:<br>
| > |<br>
| > | foo<br>
| > | foo =<br>
| > |   \ @ t_a1Za @ c_a1Zb c_a1HT n_a1HU _ -><br>
| > |     $ (. (foldr c_a1HT n_a1HU)<br>
| > |          (takeWhile<br>
| > |             (let {<br>
| > |                ds_s21z<br>
| > |                ds_s21z = I# 1 } in<br>
| > |              \ ds_d1Zw -> neInt ds_d1Zw ds_s21z)))<br>
| > |       (let {<br>
| > |          n_s21x<br>
| > |          n_s21x = I# 10 } in<br>
| > |        unfoldr<br>
| > |          (\ m_a1U7 -><br>
| > |             case leInt m_a1U7 n_s21x of _ {<br>
| > |               False -> Nothing;<br>
| > |               True -> Just (m_a1U7, m_a1U7)<br>
| > |             })<br>
| > |          ($fNumInt_$cnegate (I# 9)))<br>
| > |<br>
| > |<br>
| > | and then I get this out of my extra simplifier run:<br>
| > |<br>
| > | foo<br>
| > | foo =<br>
| > |   \ @ t_a1Za @ c_a1Zb c_a1HT n_a1HU _ -><br>
| > |     $ (\ x_a20f -><br>
| > |          foldr<br>
| > |            (\ x_a1HR r_a1HS -><br>
| > |               case case x_a1HR of _ { I# x_a20R -><br>
| > |                    tagToEnum#<br>
| > |                      (case x_a20R of _ {<br>
| > |                         __DEFAULT -> 1;<br>
| > |                         1 -> 0<br>
| > |                       })<br>
| > |                    }<br>
| > |               of _ {<br>
| > |                 False -> n_a1HU;<br>
| > |                 True -> c_a1HT x_a1HR r_a1HS<br>
| > |               })<br>
| > |            n_a1HU<br>
| > |            x_a20f)<br>
| > |       (let {<br>
| > |          b'_a1ZS<br>
| > |          b'_a1ZS = $fNumInt_$cnegate (I# 9) } in<br>
| > |        $ (build)<br>
| > |          (\ @ b1_a1ZU c_a1ZV n_a1ZW -><br>
| > |             letrec {<br>
| > |               go_a1ZX<br>
| > |               go_a1ZX =<br>
| > |                 \ b2_a1ZY -><br>
| > |                   case case case b2_a1ZY of _ { I# x_a218 -><br>
| > |                             tagToEnum# (<=# x_a218 10)<br>
| > |                             }<br>
| > |                        of _ {<br>
| > |                          False -> Nothing;<br>
| > |                          True -> Just (b2_a1ZY, b2_a1ZY)<br>
| > |                        }<br>
| > |                   of _ {<br>
| > |                     Nothing -> n_a1ZW;<br>
| > |                     Just ds_a203 -><br>
| > |                       case ds_a203 of _ { (a1_a207, new_b_a208) -><br>
| > |                       c_a1ZV a1_a207 (go_a1ZX new_b_a208)<br>
| > |                       }<br>
| > |                   }; } in<br>
| > |             go_a1ZX b'_a1ZS))<br>
| > |<br>
| > |<br>
| > | That is, neither the $ in the code nor the $ that was inserted when<br>
| > | inlining unfoldr got inlined themselves, even though both appear to<br>
| be<br>
| > | saturated. As a result, foldr/build doesn't fire, and full laziness<br>
| > | tears things apart. Later on, in simplifier phase 2, $ gets inlined.<br>
| > | What's preventing this from happening in the PostGentle phase I<br>
| added?<br>
| > |<br>
| > | David Feuer<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>
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><o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"> <o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><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><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"> <o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>