Okay, I solved the exact test case the paper proposed.

Now I've hit another problem:

> -- -- -- stupid loop
> -- `runSP loop_swap [1..10]` works
> loop_swap :: SP a a
> loop_swap = let swap (a, b) = (b, a) in loop (arr swap)

> -- loop_bufid is just a "delayed id"
> -- `runSP loop_bufid [1..10]` doesn't works :(
> loop_bufid :: SP a a
> loop_bufid = loop (Get (\a -> Get (\b -> Put a (Put b id))))

Updated gist: https://gist.github.com/thiago-negri/2e541a9f9762c727bdd4

At least I'm doing progress. :)



2013/10/14 Thiago Negri <evohunz@gmail.com>
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.