Thanks for the new reply. I've fixed the "queue" not being a real queue (see the last gist I've sent to the list [1]). The problem I was having in defining "first" was in my understanding of the execution of the arrow. I didn't realize that (>>>) is just the composition function from Category class. I tought that only the last output would be received by the second arrow of (>>>), and it would continue the stream processing from there. I was really lost. Now I see that the correct thing to do is to fit a no-op on the second stream because outputs will be delivered in pairs to the composed arrow. Sort of a BalanceLine/Merge that I've learned in my COBOL years. I will run your test cases as soon as I get home. By the way, I couldn't figure out a way to define an ArrowLoop instance that "runSP (loop (arr swap))) [1..10]" doesn't evaluate to bottom (loops forever). I don't have much time to this, but I'm trying to solve it mentally when I feel in the mood and typing some code on a 30-min/day basis. The hackage package that defines a Stream Processor as explained by Hughes uses a different definition for SP data type and has the same problem when evaluating "swap" in a loop (it throws an error) [2]. I guess this problem is harder than Hughes expected, as I find it more difficult to solve than the tricky "first" definition. Or, I may be missing something huge. (I still want to solve it by myself, but tips are welcome.) Thanks, Thiago. [1] https://gist.github.com/thiago-negri/2e541a9f9762c727bdd4 [2] http://hackage.haskell.org/package/streamproc