You say this “isn’t actually a monoid,” but that’s just not true; this is a monoid. It satisfies all the monoid laws. It wouldn’t be a monoid if we defined mempty = NotReusable, but we don’t. As-written, it’s a perfectly cromulent monoid.

(You’re right that the other instances aren’t monoids, and we should get rid of those. But this one seems fine to me.)

Yes, having taken a second look, you are right. So it makes sense to treat QueryReusability as a monoid.

I normally recommend against doing this. Why? Two reasons:

1. You can’t use MonadState for something else when this transformer is somewhere in the stack.

2. It’s a weaker abstraction. Code that is polymorphic in the monad but written against MonadReusability can only call recordVariableUse and markNotReusable, which accumulate information monoidally. But using MonadState, they can do arbitrary other things, including dropping the state altogether.

Perhaps the above two points seem like small potatoes, and maybe they are. But I don’t think they’re inconsequential enough to justify switching away from the abstraction just to be a little bit simpler!

One improvement that would be nice would be to switch from StateT to WriterT as the underlying transformer, since ReusabilityT is fundamentally about accumulating information monoidally, and it doesn’t need the full power of StateT. Alas, even the strict variant of WriterT leaks space, so I avoid using it for anything that isn’t tiny.

Fortunately, recent versions of transformers include Control.Monad.Trans.Writer.CPS, which is a non-leaky implementation of WriterT (it uses StateT under the hood), but mtl doesn’t include support for that in the currently-released version. It does support it on master (because I added support for it—probably at around the same time I wrote ReusabilityT, in fact!), but it doesn’t seem to have made its way into a release yet. I should probably bother the maintainers about that.

Thanks for this background, Alexis. I completely agree with the points you raise. I am not as well-versed in the space leakage of the various monad transformers, so what you wrote is very informative.

The reason I opened this PR nonetheless is that I think in this case the abstraction of MonadReusability has a cost. There is an argument to be made against abstraction when this is in conflict with interpretability, as it was for me. But I'm sure we can resolve this conflict in the refactored version by making sure there is good documentation, and by minimizing dependency on this stateful computation. (At first sight this seems to be much better in the refactored version, which is why above I proposed to ignore this PR in lieu of that work.)

FWIW I agree with you 100% that the “mtl-style” approach to effect composition is way, way too complicated, and we want something better. That is in fact precisely why I have written eff: I think monad transformers are the single largest obstacle to new Haskell programmers who want to get productive with the language, and I think algebraic effects are a better design.

Unfortunately, existing approaches to algebraic effects in Haskell aren’t very efficient, so eff is also a project in making them fast. And eff is fast… but it is fast because it depends on some modifications to GHC. I have an open GHC proposal to get those modifications merged, but until then we’re stuck with what we have.

So yes, less tangentially, I’m happy to include some more documentation wherever it would help. Please feel free to add some extra documentation wherever it would be helpful! (Or, for that matter, request for someone else to add some documentation if you don’t feel like you understand it enough to do it yourself.)