Skip to content

Reconsider alternative instance for Transformer typeclasses #56

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
safareli opened this issue Apr 26, 2017 · 1 comment · Fixed by #187
Closed

Reconsider alternative instance for Transformer typeclasses #56

safareli opened this issue Apr 26, 2017 · 1 comment · Fixed by #187

Comments

@safareli
Copy link
Contributor

When I first used MonadState instance for ParserT I had ParserT s (State s') a and I was expecting it to be defined as in most of transformers:

(MonadState s m) => MonadState s (ParserT s' m)

but instead it's defined as:

(Monad m) => MonadState (ParseState s) (ParserT s m)
-- `MonadThrow` and `MonadError` are defined in same fashion.

So my question is, why it's like that? I think If we had normal definitions of Monad* then ParseT would be more useful in transformer stacks (we could expose functions from this typeclasses with different name, for users to still be able to manipulate ParserT's Internal structure).

@paf31
Copy link
Contributor

paf31 commented Apr 26, 2017

Yes, we should probably break this, those instances would be more useful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

2 participants