> A recursive user-defined function will
> disrupt fusion in the pipeline Right I was thinking of cases where disrupting the pipeline might be a problem. I shouldn't have just mentioned recursive definitions, but also the use of the monad instance. In the case of stream-fusion/ co-church-encoding sorts of cases, the monad instance is often itself kind of dreadful; you do something like pack the old stream as the hidden state of a new stream, rather than using Int and StrictMaybe Int and sensible things like that for the stream state. (This is why ghc rejected a stream-fusion Data.List, if I understand; the literature is always talking about concatMap.) But it seems strange to have a producer concept where you advise the user not to make yield statements! It's sort of the whole point that they can ... or maybe I'm wrong about that. Gabriel's approach, if I understand, tries to do as well by the compiler as one can, *given* that practically everything the user will give to it will be a mass of recursive loops that employ the monad instance and so on. It isn't like a fusion approach which aims to produce a prelude the user won't depart from. But I don't know, that's the picture I ended up with. Michael -- You received this message because you are subscribed to the Google Groups "Haskell Pipes" group. To unsubscribe from this group and stop receiving emails from it, send an email to haskell-pipes+unsubscr...@googlegroups.com. To post to this group, send email to haskell-pipes@googlegroups.com.
