-
Notifications
You must be signed in to change notification settings - Fork 15
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
Local state/located effects? #8
Comments
I don't have a more obvious and cleaner solution to this problem. But I really like your idea at the end: making the local monad (the second argument to Also, the Unfolder channel looks cool. I'll definitely check out the new episode when it's out. |
Ok, thanks for thinking along! :) As for ghc support: typically when people talk about indexed monads they talk about monads where bind can change the index, of course, which doesn't work so well with Incidentally, it seems that this kind of location-specific state should be relatively common? Perhaps the constructors of |
Yes, we'll make that change. |
@edsko Thanks for featuring HasChor on the show, and thanks for all the thoughtful suggestions! We haven't released a package on Hackage yet, so now is a great time to be suggesting API improvements. |
My pleasure :) The only other thing that comes to mind that I think you could consider changing is the serialization format from |
After seeing the ICFP presentation on
HasChor
, I thought it might be nice to discuss it in the upcoming Unfolder episode (coming Wednesday).Motivation
As an example, I wanted to make a simple fileserver, where the client can send filepaths and the server responds with the contents of those files. The example in the repo use
readLine
for the client to interact with the user, but I wanted to abstract from this, and have the client be a thread that takes instructions through anMVar
; this means the client needs some state. Similar, the server needs some state too: it needs to know which directory to use as the root directory to serve files from.Not so nice solution
However, I couldn't really see an easy way to pass this state to the choreography. I can't take the two state parameters as arguments to the choreography, because the server should not need the client state and vice versa. I can take two located parameters
and pass
Empty
for the argument that is unused:but this doesn't feel terribly clean.
Better abstraction?
I tried coming up with an abstraction that makes this a little cleaner. First,
hoist
:(this definition is uncontroversial, I think). Then, since the only way to extend the
Choreo
monad is by picking a different underlyingm
, I definedthis then makes it possible to "provide local state", in a somewhat similar fashion to endpoint projection:
The choreography is now a little cleaner:
It still doesn't feel terribly satisfactory though. Am I missing a more obvious solution?
Proper solution?
It seems to me that the cleaner solution would if the argument to
Choreo
is an indexed monad of kindSymbol -> Type -> Type
. There is no reason to assume that the client and the server require the exact same of effects, after all -- indeed, it seems quite likely that they will not.The text was updated successfully, but these errors were encountered: