Monad/Monoid are a different category of things from transducers—think of them more like an interface than a thing. For instance, a basic model of Transducer is as follows
type Trans a b = forall r . (r -> b -> r) -> (r -> a -> r)
and it turns out that this is isomorphic to (e.g. an optimization of) the list Kleisli arrow
type KleiList a b = a -> [b]
and lists are monads. For a slightly different reason, this argumentation leads me to believe that Transducers ought to be monads via the Reader/List transformer stack. I haven't verified it, however.
Transducers could be monoids, too. You'd need to have two operations like so
zero :: Transducer a b
add :: Transducer a b -> Transducer a b -> Transducer a b
and perhaps there would be necessary restrictions on the choices of `a` and `b`. It's immediately obvious we could make this work if `a` and `b` were equal
zero :: Transducer a a
add :: Transducer a a -> Transducer a a -> Transducer a a
as this is now just the "identity" transducer and transducer composition which satisfy all the laws of monoid.
Transducers could be monoids, too. You'd need to have two operations like so
and perhaps there would be necessary restrictions on the choices of `a` and `b`. It's immediately obvious we could make this work if `a` and `b` were equal as this is now just the "identity" transducer and transducer composition which satisfy all the laws of monoid.