<p dir="ltr"><br>
On Aug 3, 2012 11:13 PM, "Brandon Simmons" <<a href="mailto:brandon.m.simmons@gmail.com">brandon.m.simmons@gmail.com</a>> wrote:<br>
> In particular I don't fully understand why these sorts of contortions...<br>
><br>
> <a href="http://hackage.haskell.org/packages/archive/base/latest/doc/html/src/GHC-List.html#foldl">http://hackage.haskell.org/packages/archive/base/latest/doc/html/src/GHC-List.html#foldl</a><br>
><br>
> ...are required. It seems like a programmer has to throw "equational<br>
> reasoning", separation of concerns, and all the little elegant bits<br>
> about the language out the window just to indicate something boring to<br>
> the compiler.<br>
><br>
> Disclaimer: The following is less a proposal meant to be taken<br>
> seriously, and more me trying to better understand things.<br>
><br>
> Could the following be used as syntax for indicating inlining? Rather<br>
> than relying on the syntactic LHS, instead let that be specified in<br>
> the type signature...<br>
><br>
> foldl :: (a -> b -> a) -> a -> [b] -> {-# INLINE #-} a<br>
> foldl f z [] = z<br>
> foldl f z (x:xs) = foldl f (f z x) xs<br>
><br>
> ...indicating, in this case, that foldl should be inlined when<br>
> "fully-applied" means its first three arguments (I guess that's the<br>
> intent of the original version linked above?). Then (waves hands) the<br>
> compiler could do the necessary transformations that the programmer<br>
> had to do to foldl above. Maybe what I'm proposing is actually a<br>
> separate NORECURSIVE_TRANSFORM pragma or something</p>
<p dir="ltr">That's not quite the effect. What has been done to foldl there is known as the static argument transform. It avoids passing constant arguments along in recursion. f is the only static argument to foldl (foldr by contrast has two).</p>
<p dir="ltr">This can be important for multiple reasons. Sometimes it frees up registers. Here, we may inline foldl and possibly specialize the loop to a statically known f. That is often a big win. For instance, if you write sum with foldl, you can inline, do a worker wrapper transform, and work on unboxed integers with raw adds (probably) instead of going through multiple layers of indirection.</p>
<p dir="ltr">There was some work on making GHC automatically SAT, but of it's a bit tricky with regard to when it's worth it, so I don't think it's been put in.</p>
<p dir="ltr">I have code that relies on this sort of thing a lot, so if someone comes up with a good way to automate it, I wouldn't complain.</p>
<p dir="ltr">Dan</p>