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 > [email protected] > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list [email protected] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
