Do we actually want to be using a local Freer monad?

[ShapeOfMatter]

What's considered best-practice these days? Probably not Polysemy; is there a "normal" choice?

[psilospore]

I'm not too familiar with the effects ecosystem but I remember others talking positively about https://github.com/haskell-effectful/effectful what do you think? But that might have been more performance related which might not matter for our use case. I am slightly familiar with it. I can do an initial stab and see how it goes if you think I should try.

[psilospore]

Browsing the internets it's kind of hard to tell if there's much consensus. This might be useful https://discourse.haskell.org/t/the-issues-with-effect-systems/5630/12

Someone saying they are largely equivalent https://www.reddit.com/r/haskell/comments/12im0z9/comment/jg01613/

Maybe I'm mixing up effects systems and free monads

[ShapeOfMatter]

I think the distinction between effect systems and freer monads is simply that free monads are one mathematical abstraction you can use to build an effect system. (free monads are not different from freer monads in any way we care about, and algebraic effects in the mathematical sense are borderline impossible and nobody seems to care)

[ShapeOfMatter]

Having read the discourse.haskell.org thread, I'm thinking we probably shouldn't change anything about how we're doing things.

• We don't much care about efficiency for the purpose at hand. Or rather, we're tentatively assuming that local computation won't be the bottleneck in choreographies; the efficiency gains effect systems are fighting over aren't motivating for us.
• We probably don't want to be writing our library as "an effect" for use in an effect system. Leaving aside the question of which system we'd be locking our users into, simply including Choreography in the list of effects an effectful program uses is... uncharted territory? Unsound? Makes the order of effects in the stack suddenly matter a lot? Let's not make that our problem (today).
• HasChor, in terms of it's exposed API, is actually a monad transformer; it has an inner monad over which the type is parameterized, and given said monad a "choreography" is simply a concrete monad comparable to IO. This is similar to the way Pirouette is an outer language parameterized by an inner "host" language, which I think is probably a good way to write choeographies.

I think the question at hand is implementation, and shouldn't affect the exposed surface of our library. So the advantage of HasChor's approach of packaging their own freer-monad module is that it saves them dependencies (which matters!). I don't think this is the end of the conversation, but right now I'm feeling like the mixing of choreographies with modern effect systems might be a later project.

[psilospore]

Ok that makes sense to me. I also don't see a great reason to move to another effect system at the moment.

[ShapeOfMatter]

If we're in agreement that we're not changing implementation this month, then let's close this issue?