Indeed. In fact, I believe it's an equivalence: if FUN 'One r is an applicative functor, then r is dupable (i.e. a comonoid). I think this free with the lax-monoidal functor presentation of applicatives (but I didn't work out if the laws actually align, surely they do).

Question: do you need that soon (aka should I cut a release)?

Indeed. In fact, I believe it's an equivalence: if FUN 'One r is an applicative functor, then r is dupable (i.e. a comonoid).

Agreed! We can use (,) <$> id <*> id to implement dup.

I think this free with the lax-monoidal functor presentation of applicatives (but I didn't work out if the laws actually align, surely they do).

Sounds interesting, let me know if you make it out!

Question: do you need that soon (aka should I cut a release)?

Well, they are definetely useful (for, e.g., duplicating Linearly tokens until linear constraints land in GHC), but we can do the same thing with Reader monads. So I'm not in a hurry :-)

It's likely that I avoided adding a monad for FUN 'One because I don't like the error messages that you get when you forget an argument in a monad. But they aren't really much better without a monad instance, presumably. So let's merge this.

I'll cut a release in January.