Why is unlifting strategy a property of Eff, and not individual effects?

[ocharles]

Branching out from #157, I realize I've never quite understood why unlifting strategies exist at all. They seem to be a unique aspect to effectful, and I don't recall seeing anything similar in any other effect libraries. It seems surprising to me that this is a property of Eff as a whole, and not a choice made by each individual effect (or perhaps its handler). The most surprising part is that changing the unlift strategy has a dynamic action-at-a-distance effect, completely changing how a program runs. I suppose my fundamental question is why bother with this at all - can we not have individual effects choose how to duplicate or share their environment? We already do this, with .Shared and .Local.

[arybczak]

They seem to be a unique aspect to effectful, and I don't recall seeing anything similar in any other effect libraries

Yes, because effectful is the only library that offers thread local state and the MonadUnliftIO instance (in principle cleff is another one, but its thread local state has a funky behavior when forking, i.e. it resets to the initial value).

It seems surprising to me that this is a property of Eff as a whole

It's not, it's a property of the IOE effect.

not a choice made by each individual effect (or perhaps its handler)

It is though ;) There are specific unlifts for static and dynamic effects.

When using functions with the MonadUnliftIO constraint there, with static effects you go to IO with unsafeEff_/seqUnliftIO/concUnliftIO and with dynamic effects with localUnliftIO, thus the current unlifting strategy of IOE is not relevant.

It's only if you use these functions directly in some IOE :> es => Eff es, then the unlifting strategy of IOE is considered.