Wolfgang Jeltsch wolfgang-it at
Fri Sep 1 21:49:22 UTC 2017


Both the sliding law and the nesting law seem to make sense for
FunctorFix. The other two laws seem to fundamentally rely on the
existence of return (purity law) and (>>=) (left-shrinking).

However, there is also the scope change law, mentioned on page 19 of
Levent Erkok’s thesis ( This
law can be formulated based on fmap, without resorting to return and
(>>=). Levent proves it using all four MonadFix axioms. I do not know
whether it is possible to derive it just from sliding, nesting, and the
Functor laws, or whether we would need to require it explicitly.

Every type that is an instance of MonadFix, should be an instance of
FunctorFix, with ffix being the same as mfix. At the moment, I cannot
come up with a FunctorFix instance that is not an instance of Monad.

My desire for FunctorFix comes from my work on the new version of the
incremental-computing package. In this package, I have certain
operations that were supposed to work for all functors. I found out that
I need these functors to have mfix-like operations, but I do not want to
impose a Monad constraint on them, because I do not need return or

All the best,

Am Mittwoch, den 30.08.2017, 16:30 -0400 schrieb David Feuer:
> I assume you want to impose the MonadFix sliding law,
> ffix (fmap h . f) = fmap h (ffix (f . h)), for strict h.
> Do you also want the nesting law?
> ffix (\x -> ffix (\y -> f x y)) = ffix (\x -> f x x)
> Are there any other laws you'd like to add in place of the seemingly
> irrelevant purity and left shrinking laws?
> Can you give some sample instances and how one might use them?
> On Wed, Aug 30, 2017 at 2:59 PM, Wolfgang Jeltsch
> <wolfgang-it at> wrote:
> > 
> > 
> > Hi!
> > 
> > There is the MonadFix class with the mfix method. However, there are
> > situations where you need a fixed point operator of type a -> f a
> > for
> > some f, but f is not necessarily a monad. What about adding a
> > FunctorFix
> > class that is identical to MonadFix, except that it has a Functor,
> > not a
> > Monad, superclass constraint?
> > 
> > All the best,
> > Wolfgang
> > _______________________________________________
> > Libraries mailing list
> > Libraries at
> >

More information about the Libraries mailing list