MB> I think there are some problems with your implementation of MB> "first". Here are some examples which don't behave the way I would MB> expect: You are right. I have a problem and I need to think of it a bit more. MB> My first attempt was to use explicit queues: So was mine. But then I thought I can replace queues by function composition; seems that I took a wrong step somewhere. *Main>> runSP (Put 42 returnA) [] MB> [42] *Main>> runSP (first (Put 42 returnA)) [] MB> [] MB> In the second case, I think the answer should really be [(42,_|_)]. I think, your implementation handles this correctly. Stream processors are supposed to handle infinite lists, not finite ones; so, if we continue feeding (first (Put 42 returnA)) with data, it would be able to output (42,something) instead of (42,(_|_)). MB> Same goes for mapA given in the tutorial [2]. This problem also MB> prevented me from defining an instance of ArrowLoop. Seems to be the same problem I have. It was stated at the end of my posting. MB> So, I don't think explicit queues are the answer. I suspect one MB> needs to use the circular/lazy programming technique described in MB> section 2.3 [2] to implement the basic Arrow combinators, as well MB> as ArrowLoop. With some luck, that might solve both of the above MB> problems. Tried that, but failed. Seems that this technique works only for very lazy stream processors - such as SF - and SP are more strict. There is a presentation "Arrows for Fudgets" by Magnus Carlsson, which explains that stream processors (SP) are not Hughes' arrows, but more general ones, with (,) bifunctor replaced with Either.