Like interpretFinal specialized to IO, but also tries very hard to preserve state semantics dependant on the order interpreters are run, adressing the primary issue with Final.

Semantically, interpreters written using this behave very much as though they were written using withLowerToIO. However, this does not need to spawn an interpreter thread, making it more efficient (but not any more safe.)

interpretFinalGlobal operates under the assumption that any effectful state which can't be inspected using Inspector can't contain any values. For example, the effectful state for runError is Either e a. The inspector for this effectful state only fails if the effectful state is a Left value, which therefore doesn't contain any values of a.

The assumption holds true for all interpreters featured in polysemy, and is presumably always true for any properly implemented interpreter. interpretFinalGlobal may throw an exception if it is used together with an interpreter that uses weave improperly.

asyncToIOFinal implemented using interpretFinalGlobal.

This behaves semantically very much like asyncToIO, but doesn't need to spin up an interpreter thread, making it more efficient (but not any more safe).

resourceToIOFinal implemented using interpretFinalGlobal.

This behaves semantically very much like resourceToIO, but doesn't need to spin up an interpreter thread, making it more efficient (but not any more safe).