Skip to content
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

Add hoistClient to servant-client #936

Merged
merged 4 commits into from Apr 9, 2018

Conversation

Projects
None yet
3 participants
@alpmestan
Copy link
Contributor

commented Apr 3, 2018

It's defined in terms of this new typeclass method of HasClient in servant-client-core:

class RunClient m => HasClient m api where
  [...]
  hoistClientMonad
    :: Proxy m
    -> Proxy api
    -> (forall x. mon x -> mon' x)
    -> Client mon api
    -> Client mon' api

Note that we don't expect source clients to live in the http client backend's m monad, so that we can say start from ClientM, go to some custom monad App, and finally land back in IO, using two successive calls to hoistClientMonad, or one that composes the transformations. This just seems like the right choice, because it's the most flexible option.

Feedback welcome!

@alpmestan alpmestan added this to the 0.14 milestone Apr 3, 2018

@alpmestan alpmestan requested review from phadej and jkarni Apr 3, 2018

@jkarni

This comment has been minimized.

Copy link
Member

commented Apr 4, 2018

I'm about to be away from the internet for ten days, and am happy with this. One question though: isn't it already possible to do what hoist does simply by defining a new RunClient instance for the monad?

@alpmestan

This comment has been minimized.

Copy link
Contributor Author

commented Apr 4, 2018

@jkarni Maybe, yeah, except that a typeclass instance has to be provided for each target monad, and I think you're pretty much stuck with just one transformation per monad (you'd define the instance for TargetMonad as transformations over the instance of SourceMonad) so it's static. While with hoistClient you get to pick the transformation, and it can be dynamic: partially applying some arguments from some context first and finally transforming the return type of clients.

Not sure whether you were suggesting to refactor the PR in terms of RunClient instead or not, but I'm failing to see the advantages so I'm thinking probably not and that you were just curious. =) (or I might be overlooking something?)

@alpmestan

This comment has been minimized.

Copy link
Contributor Author

commented Apr 6, 2018

No other feedback? Should we merge?

@phadej phadej merged commit 6be8291 into master Apr 9, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@phadej phadej deleted the alp/hoistClient branch Apr 9, 2018

@alpmestan alpmestan referenced this pull request Apr 11, 2018

Closed

Implement "hoistClient" #927

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.