Open edsko opened 1 year ago
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 Choreo
) indexed by a location so each node can have different sets of effects. This should be relatively easy to implement. One thing I'm a little unsure of is how well GHC supports this kind of indexed monad. I hope I can express it as simply as you did in your example without using language extensions and tricks.
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 do
. Simply having an additional type parameter should be fine.
Incidentally, it seems that this kind of location-specific state should be relatively common? Perhaps the constructors of (@)
should be exported from Choreography
?
Incidentally, it seems that this kind of location-specific state should be relatively common? Perhaps the constructors of (@) should be exported from Choreography?
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 Show
/Read
to maybe binary or CBOR or something.
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.