Yes indeed, this is what some fusion code could look like. I deal with stuff like this: mk i j = enumFromN (i+1) (j-i-2) -- gen indices, sometimes index pairs f i j k = T!(i,k) + T!(k+1,j) -- table lookup using some 2d tables g i j k = fun i k + fun (k+1) j -- some funny calculation z i j = minimum $ zipWith (+) (map (f i j) $ mk i j) (map (g i j) $ mk i j) y i j = minimum (map (g i j) $ mk i j) So i would like to split my calculations into f and g as sometimes (in backtracking results) only g is needed. Furthermore, there are like 12 different f g z y mk each. Being able to seperate the worker into f g means cleaner code and that it is easier to change stuff. Note that mk in f is always called with the same borders, leading to things like my original problem. But Roman has already pointed out how often this duplication of counters can occur. Gruss, Christian PS: above is a bit pseudocode-like but captures the essentials and my thumbs are numb now... ;-) ----- Original message -----

On 06/11/2010, at 02:27, Sebastian Fischer wrote:

...

Interesting. This approach requires `f` to be inlined into its call site in order to eliminate the redundant argument. This is different from the proposal to provide a specialized version of `f` (where the arguments are combined) which could be reused at different call sites.

Which proposal do you mean? I'm not sure something like that is feasible without knowing the call sites. You have to know which arguments to combine.

...

How many call sites with identical arguments are there in the generated code that triggered this discussion and in the stream fusion code that would benefit from this optimization?

In stream fusion code, there is normally exactly one call site. I suspect that the Christian's example has also been derived from stream fusion code.

Roman

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users