Annotation for unfolding wanted

Georg Martius georg.martius at
Tue Jul 31 09:52:53 EDT 2007

Hi Simon,

thanks for the answer! I see why inlining is not a good idea, but why is it 
not unfolded. I mean we don't need any true recursion if the function is 
tail-recursive or am I mistaken?
However my point was more on a semantic point of view: If I write a function 
in a recursive way, but actually do nothing else than a loop, I would like 
a) that the compiler unrolls it to a loop and
b) that I can specify such a requirement, while violating it emits an error. 

I believe it would help to write the intended code straight away, especially 
for less advanced Haskell programmers, which don't know about the 
optimization details of the compiler.


On Tuesday 31 July 2007 11:22, you wrote:
> | I was wondering why we don't have an annotation or pragma for function to
> | tell the compiler that we _need_ this particular recursive function to be
> | unfolded. If the compiler cannot do this for some reason it should
> | produce an error message to help you modifying your code. I have
> | regularly problems that my code is either not strict enough or my
> | functions are not unfolded. I find it annoying that this is a regular
> | show stopper and consumes much time to fix. Here is an example: a search
> | function for strings, which should return the index and the rest of the
> | string after the first occurrence: search0 will not be unfolded by ghc -O
> | even with {#- INLINE search0 -#} (I don't know why, it looks
> | tail-recursive to me)
> GHC never inlines recursive functions.  Why not?  Because doing so exposes
> a new inline opportunity.  How many times would you like it inlined?  Not
> forever, I assume!
> Some compilers unroll recursive functions by inlining them N times, for
> some fixed N (say 3 or so).  This reduces the loop overheads.  GHC doesn't
> do this, although it'd be nice, because it makes repeated traversals of the
> code, and it's hard to spot when the function has been unrolled 3 times and
> then stop.  If you look at the code after unrolling 3 times, from scratch,
> there's another call just waiting to be inlined.
> I'm not saying this couldn't be improved -- but I don't see an easy way to
> improve it.
> Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :

More information about the Glasgow-haskell-users mailing list