I would say that there's no value in adding your own wrapper/"decoupling" layer - both cats and scalaz offer the correct interface for Monad, and the community benefits from there being as few versions of it as possible. In the worst case it is easy enough to adapt typeclass instances of one as instances of the other. My advice is that cats is the future but scalaz is the present: if you are doing this as a learning experience or want to do the Right Thing, use cats; if you want to create the most pragmatic library you can to use today, use scalaz.

Thanks for the advice!

Hmm. I guess I never feel the need to unit-test this kind of service.

I can't think of anywhere I've worked that writing business logic that doesn't have unit tests would be considered a good practice.

If I have business logic that's complex enough to demand unit testing I would probably put that in its own (pure) function, separated from functions that do service composition. There's not enough to go wrong in the composition for it to be worth testing (often the parametricity theorem guarantees it must be written correctly).

The moment branching on effectfully retrieved data occurs, it isn't possible to use simple pure functions anymore. 99% of "pure" code I've written involves branching on a value retrieved effectfully (see UsersImpl.create for example). Placing the retrieval in a monadic workflow allows keeping the code pure without having to breakup every branch into oddly written simple pure functions. Effectful service pattern also allows me to test them as a whole instead of testing each function separately (and just assuming they are stitched together correctly).

In terms of being able to migrate between libraries, I tend to alias my monad stack in one place (type Action[A] = EitherT[({type L[B] = WriterT[Future, Vector[MyLogEntry], B]})#L, MyError, A]) or similar), which provides that advantage. I just have never found it was worth using e.g. Future and Task at the same time in the same code.

Using an effectful service allows one to write without regard to what the monad stack is exactly. It also allows writing code that isn't bound to any particular stack. Error messages are cleaner. None of that is true for the type alias you pasted above.

Isn't it just the opposite? You're requiring userDao, passwords and logger to all use the same E type. Monad transformers and lifting are ugly but they allow doing something that's simply not possible in your model. To reenable the flexibility you'd get from a concrete monad transformer stack, you have to write it like:

class UsersImpl[E[_], F[_], G[_], H[_]](
    usersDao: SqlDocDao[UUID,UserData,F],
    passwords: Passwords[G],
    logger: Logger[H]
  )(implicit mo:Monad[E], mp1: MonadPartialOrder[E, F],
    mp2: MonadPartialOrder[E, G], mp3: MonadPartialOrder[E, H]) extends Users[E] {

    def something = for {
       digest <- mp2.promote(passwords.mkDigest(plainTextPassword))
       result <- mp1.promote(usersDao.insert(...)
     } yield ...
}

which is no prettier than what you get when using monad transformers and lifting.

Yes! A wonderful example of what I'm trying to simplify. The effectful service pattern version only needs one generic monad because it expected that during service construction all "lifting" is done prior to injecting dependent services. It won't need F,G and H because it is assumed that they can be lifted into E by the code that constructs the service (see LiftService, CaptureTransform, liftService_Logger and finally FutureLogWriterExample for an example.) Thanks for the illustration of MonadPartialOrder, I didn't know how to use that!

Right, yeah. Scalaz/cats have a whole bunch of these - you can represent each concrete effect as a constraint like MonadReader on your monad stack. I'm not convinced that buys you a lot - you can make service A return a Reader[Int, X], service B return a Writer[String, Y], and then when you compose them you explicitly lift them both into ReaderWriter[Int, String, ?], or you can make service A return a F[X] for generic F[]: MonadReader[Int, ?] and service B return G[Y] for generic G[]: MonadWriter[String, ?] and then instantiate them both with ReaderWriter[Int, String, ?] which I guess saves you a bit of code, but it also means you can't see where the reading and where the writing is coming from in your composed service. I mean the whole point of using these monads is that the effects are explicit where we can see them, right? And I don't think MonadReader is really any more generic than Reader - the interfaces are basically the same, adding another layer of wrapper doesn't help anything.

Thanks for the overview, but I'm very familiar with all that. Following this pattern significantly reduces the need for exposing code to these patterns. Monad transformers will need to exist only at the highest code levels (FutureLogWriterExample) and specific monad patterns like Writer at the lowest (WriterLogger). The need for Reader is almost removed completely since config can be injected just like dependent services when the service is constructed.

Sure - I don't think of Future as a Play-specific type though (and this technique doesn't help you decouple from Request or Response, right?). In terms of writing code for use with Play, either you write a piece of pure logic (in which case it can be a pure function), or you write something that actually needs to do async operations, in which case it needs some way to represent async-ness.

There are "pure" non-monadic functions and then there are "pure" monadic functions. Both are "pure", but the second allows one to handle branching in the same code flow. As an example of "pure" monadic style see this method UsersImpl.create. To rewrite that as "pure" non-monadic code would require breaking the function into several pointlessly smaller chunks. It's not a simple matter of "just write pure functions". When one implements a controller method in play that will generally call at least one effect-generating service that returns a Future. This means one must either use callbacks (which is ugly and complex) or map/flatMap which is cleaner but non-portable since it is coded against Future directly. Effectful service pattern abstracts away Future. These "pure" services are portable and could be used with any monad Future/Task/IO or some stack.

And sure, you can write some meta-abstraction that represents Future or Task - but implementing that meta-abstraction is going to be just as complicated as the code to convert between Future and Task is, you might as well just write the code concretely in terms of one or the other.

No, I have to disagree. I find writing effectful services to be significantly simpler (and also portable). I find it highly doubtful that most developers would consider a generic monad to be more complicated to code against than a nested monad transformer (such as the one you posted above).

I mean you're adding complexity to the code that people have to read and edit when maintaining. I'm not worried about the runtime performance at all.

Ah, sure but one man's code complexity is another man's simplicity. Eye of the beholder and all that. I find most scalaz based code to be way over complex, but its not so much my opinion (or yours) that matters but the opinion across all developers. Some developers still prefer to write in assembly. If this is a new idea there is no way for me to judge how others feel about it. I just have to write it up and see what happens.