Dear Akio, Am Freitag, den 31.01.2014, 16:54 +0900 schrieb Akio Takano:
Can you implement build via buildW, so that existing code like "map" [~1] forall f xs. map f xs = build (\c n -> foldr (mapFB c f) n xs) can be used unmodified? But probably not... but that would mean a noticeable incompatibility and a burden on library authors using list fusion.
You can implement build in terms of buildW. However any list producer defined using that definition of build would produce good code if the final consumer is a left fold. The resulting code will be in CPS. On the other hand, I imagine that if we also annotate foldl with oneShot, this problem may become less severe.
Hmm, I guess my question was not precise enough. Let me rephrase: To what extend can you provide the exsting foldr/build API _without_ losing the advantages of your approach? Or put differently: Could you add a section to the wiki that serves as a migration guide to those who want to port their producers and consumers to your system, without having to fully understand what’s going on? Another thing that would be very interesting: Your framework seems to be quite general: Are there other useful worker-wrapper-transformations that one would possibly want to apply to a fused computations, besides the one that makes foldl work well? Other examples of w/w-transformations in GHC include * Unboxing of parameters * Unboxing of return values, returning multiple values but maybe you can think of other interesting examples. Am I right that the _consumer_ of a fused computation decides which worker-wrapper pair to use? I still quite like the approach, mostly because it does so well for lists. I still have to fully grok it, though :-) Greetings, Joachim -- Joachim Breitner e-Mail: mail@joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nomeata@joachim-breitner.de