Closed JordanMartinez closed 3 years ago
I'd prefer to wait until we have a concrete use case for it, personally.
I am trying to port hedgehog to PureScript and they use it. That's why I opened this issue. However, I can keep that code in the port until we have more use cases than this.
Ah okay, I reckon that probably counts. Can you describe how it's useful for your hedgehog port?
It is used to create 3 different type class instances and I'm guessing that TreeT
is somehow affected by it:
Instance definitions don't really justify the existence of IdentityT though, I think the part that's more relevant here is places where those instances would be used. I think perhaps similarly to how identity
is useful for functions which take functions as arguments, IdentityT
could be useful for types which take monad transformers as arguments. Does hedgehog have any of those?
IdentityT
could be useful for types which take monad transformers as arguments.
Yeah, that would make sense. Similar to how Identity
acts like a placeholder monad argument.
After looking around a bit more, seems like distributeT
from MonadTransDistributive
has a MFunctor
constraint that takes a monad transformer as an argument. However, the purescript port of mmorph's MFunctor
doesn't have an instance for IdentityT
. I imagine it's because IdentityT
isn't included in this library. Does that concrete example suffice?
Yep, that works for me.
I can submit a PR for this. However, what should the file's module name be? Control.Monad.Identity.Trans
?
Yep, that conforms to the convention we're using in this library.
For context, this is included in the Haskell 'transformers' library