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