Closed k0001 closed 9 years ago
huh. I really thought there'd be knot tying issues but after testing them out with the programs I had already written, everything seems to still work out. I'm a bit apprehensive but I'll play around with this some more and see the situations where this would break. Thanks :)
Nevermind, was running my tests against the the MonadFix version by mistake, heh. Yeah, definitely immediate knot-tying issues with most usages of rec
with the Non-MonadFix verison. That's because mfix
is needed to lift knot-tying semantics from fix
into a Monadic context...to let fix
"know" what can be tied for a given Monad
instance (which often times isn't just the constructor). If Cont
doesn't have a MonadFix
instance, it's because you can't write recursive bindings in Auto
with it.
Still appreciate the effort though...because seeing MonadFix
can have a "scary" factor when first seeing it, heh...which might throw people off at first. I mostly ignore it myself these days...but I did have someone did bring it up as a comment when they first read it.
@mstksg thanks for the lesson! I'll sit down and learn a bit more about what makes mfix
different from fix
.
@mstksg I am not really sure about this change, maybe
MonadFix
brings something to the table which I'm not realising. Anyway, here I go.This change removes the
MonadFix m
constraint onArrowLoop (Auto m)
, thus avoiding the propagation of theMonadFix
constraint to all otherAuto
s whenever you useproc
notation'srec
orControl.Arrow.loop
on one of them.Monads “out there in the wild” are often missing their
MonadFix
instances, and others such as asContT
can't get one due to the way they are definied, so this change will prevent the introduction of orphan instances ornewtype
wrappers just to useAuto
s recursively.I haven't really thought this through extensively, I don't fully understand the implications of this change, but I wanted to share it with you in case you want to consider that at some point.