Hello list! Currently I am working a end user application. Through the years I had incorporated the advice from r/haskell that classes without laws were not desirable. Their lack meant that we didn't have a contract boundary that should be respected by the instances. They secretly could `throw exc` on their implementation and you wouldn't notice. But on the current app I am working on, I follow the advice from this blogpost [1] that I should use classes for domain modelling. This manifest on classes like class UserQueryCapability f where getUser :: Id -> f User for interacting with a DB. Functions can be written against the interface and I can mock up with QuickCheck some pretty broad cases. The classes usually don't have a superclass constrain on `Monad` as in `MonadReader` because I *cannot* establish a law relating the monadic behavior and `getUser`. The name has Capability in it and not Monad because I won't lie that way. Making sure that these effect classes are orthogonal is something I have to check by hand. But in the back of my head there is the concern about the lack of laws could bite me even on a end user-app. Is my intuition well founded that this case is OK? Thanks for your time! [1]: https://www.parsonsmatt.org/2018/03/22/three_layer_haskell_cake.html -- -- Rubén. pgp: 4EE9 28F7 932E F4AD