PolyKinded MFunctor - Githubissues

Gabriella439 / Haskell-MMorph-Library

Monad morphisms

BSD 3-Clause "New" or "Revised" License

47 stars 26 forks source link

PolyKinded MFunctor #29

Closed jkarni closed 7 years ago

jkarni commented 7 years ago

Currently MFunctor has kind (* -> *) -> * -> *. Is there any reason not to adopt the more general (* -> *) -> k -> *? The general use-case is making things like vinyl records instances (with hoist = rmap).

(By the way, I've always really liked this library, and this seems like a good occasion to say so!)

Gabriella439 commented 7 years ago

Alright. I'm usually reluctant to make type classes poly-kinded but I think there is a sufficiently compelling case here because:

There is only one kind parameter, so it won't deteriorate the generated haddocks that much
It has an immediate practical application in vinyl ...
... which would still obey the hoist laws (i.e. hoist id = id, hoist (f . g) = hoist f . hoist g)

Would you be able to write up the pull request for this? If not, I can do it

Gabriella439 commented 7 years ago

Fixed by #30

I can upload this to Hackage if you don't have any other pending changes you'd like to submit

Gabriella439 commented 7 years ago

I had to revert this change due to #32

jkarni commented 7 years ago

Fair enough - thanks for letting me know!

treeowl commented 7 years ago

Should this be reopened? It seems the underlying problem has been fixed in GHC, according to comments in #32.

Gabriella439 commented 7 years ago

My only question is whether or not this requires a major version bump or not if we reintroduce this. I'm reviving the discussion in that issue

Gabriella439 commented 7 years ago

Alright, so the plan is to reintroduce this change but with a major version bump so that downstream libraries that might be affected by the GHC bug (and/or kind inference ambiguity) aren't affected.