Open BebeSparkelSparkel opened 4 months ago
(Earlier message was a mistake; sorry for noise.)
Is this basically the same concept as LiftingAccum
and LiftingSelect
? If so, why not follow that convention, or propose aliasing those newtypes to Bypass
?
I appreciate the established convention you pointed out. So, for the case above propose to create LiftingReader
?
The reason we don't have LiftingX
for every X
at the moment is because DerivingVia
wasn't in our support window until recently. I have no objection to adding such a type class for every 'capability type class' we support.
@kozross Where do I find what is in your support window?
I have implemented a partial example for LiftingReader. Can you check if this is what you are looking for?
Is there anything else that needs to be discussed before I finish this up for MonadReader, MonadWriter, and MonadState?
I have tried a different approach for LiftingWriter
and am using a type family and mapping classes. Let me know what you think of this.
@rhendric Could you review the changes since your last review?
I see no glaring issues.
@kozross Could you check if this is ready to pull?
When creating a new transformer it is often composed of other transformers. The transformers that it is composed of usually have specific purposes that are unrelated to the more general uses of the Monad classes and typically you still want to define the Monad instances for the underlying monad.
My real world use case is the
where I still want to have MonadReader but not for reading Handle but rather the r for m
instance MonadReader r m => MonadReader r (FileT w m)
This is a bit annoying for this case but even more so for transformers wrapping RWS. In just the ReaderT case the following must be defined
DerivingVia seems to be a better option for this by using
Bypass
There could probably a more succinct way to write the derivation but this is what I have so far.