Why don't you check yourself?
AFRP, if I recall correctly, has Arrow and ArrowLoop. So the combinators we need follow:
Using a ~> b as shorthand for Behavior a -> Behavior b.
-- From Arrow
arr :: (a -> b) -> (a ~> b) first :: (a ~> b) -> ((a,c) ~> (b,c))
(>>>) :: (a ~> b) -> (b ~> c) -> (a ~> c)
arr = fmap first f ac = liftA2 (,) (f (fst <$> ac)) (snd <$> ac)
(>>>) = (>>>) -- From ArrowLoop
loop :: ((a,c) ~> (b,c)) -> (a ~> b) loop f a = let bc = f (liftA2 (,) a (snd <$> bc)) in fst <$> bc
So that's a positive on all the arrow combinators. You have to check the supplied primitives, too, such as integral and pswitch. Once you do that, you could even implement a ClassicFRP arrow and use that instead of the Yampa arrow, so the client code wouldn't need to be changed at all.
What I have just described is the ideal situation. Here are some of the practicalities you might run into:
* AFRP models events as signals of Maybe. Semantically speaking, signals of Maybe don't have nice eventy properties, such as discrete occurrences, so you might have some difficulty translating between the two. I'm currently exploring an arrow model that accounts for events properly, but that probably doesn't help you.
* The above "loop" combinator is key to eliminating quadratic behavior in certain classic FRP situations, and I believe the reason arrows were explored to begin with. See "Plugging a Space Leak with an Arrow" by Hudak and Liu[1] for more. In Fran-like systems, there is another fix for this leak, in exchange for loss of perfect reactivity (making a "discrete memo table" of sorts).
[1]
www.cs.yale.edu/~hl293/download/leak.pdf