
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
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).