Hi,
-- I almost sure this is correct, since it is copied -- from "Programming with Arrows", J. Hughes mapA :: (ArrowChoice a) => a b c -> a [b] [c] mapA f = proc input -> case input of [] -> returnA -< [] z:zs -> do y_ <- f -< z ys_ <- mapA f -< zs returnA -< y_:ys_
Yes, this is correct. However, the ArrowChoice instance in Netwire has always been questionable. The correct (and much more efficient) way to implement mapA is as a primitive combinator much like the parallel switches in Yampa. The Netwire implementation and API has been more focussed on providing features over reasonable semantics, and that eventually led me to abandon it in favour of a more minimalistic library that is easier to reason about (wires). Please consider Netwire deprecated and I recommend you don't use it for new applications, if possible. I'm still open to reviewing and merging code contributions to support legacy applications, but other than that I would much prefer to just let it become a piece of AFRP history. =) If you must use AFRP, I recommend either my new library called wires, or the progenitor of all, Yampa. However, unless you have a strong reason to use arrowized FRP I would recommend that you go with one of the first-class FRP libraries. I currently recommend either: * reactive-banana: very simple and easy to learn API, plus the author runs a blog with lots of information on FRP. This is the library I recommend to FRP beginners. Or * reflex: my personal favourite, more focussed on practical concerns and efficiency, a more versatile API that easily integrates with applications with a "main loop", such as real-time games. The trade-off is far less documentation and a more complicated API. Sorry for not directly addressing your question, but I hope I convinced you to just switch to a different library. =) Greets ertes