Hiya, That would certainly explain why I found it difficult. Here's the original definition: liftMLabel :: Monad m => a :-> b -> m a :-> m b liftMLabel l = label (liftM $ get l) (liftM2 $ set l) Are here's a sample iteration of me hacking around: liftMLens :: Monad m => a :-> b -> m a :-> m b liftMLens l = lens getter modifier where getter = liftM $ get l modifier mf mm = mf >>= \ f -> modify l f `liftM` mm I only ever seem to replicate liftM2 characteristics when trying to brute force an implementation. And the implementations get more and more brutish as time goes on! It makes me wonder if the implications of fclabels `m a :-> m b` are radically different now, bearing in mind the original code worked. The fclabels :-> type operator has convinced the compiler that `m b -> mb` is required for the actual value modifying function. Does `m a :-> m b` make sense for the latest releases of fclabels? Is it just the lifting that's a problem? Si On Thu, 10 Dec, 2015 at 3:02 PM, Daniel Bergey wrote:

On 2015-12-10 at 07:43, Simon Peter Nicholls wrote:

...

So I figure I need:

neededLift :: (Monad m) => ((b -> b) -> a -> a) -> (m b -> m b) -> m a -> m a

I don't believe `neededLift` is possible. The type says that given any function `m b -> m b`, you can turn that function into one of type `b -> b` (as input to the lens).