eff VS in-other-words

cleff's Eff monad is esentially implemented as a ReaderT IO. [...] This is first done by eff, [...]

Here is link number 1 - Previous text "eff"

This is essentially how continuation based effect systems work, check out eveff and eff.

Languages such as Koka only support algebraic effects, not scoping operations such as catch and listen. The Effect Handlers in Scope paper introduces scoping operations, which lead to the Haskell libraries fused-effects and polysemy, but they turned out to have some weird semantics. eff is her effort to fix that.

While her eff is still under construction, there are relative more mature pieces like Koka etc. I'd very much like to understand how her concerns map to those other effect systems, but can't find more write-ups about the design space of effect systems.

There are a few languages that have algebraic effect systems, most notably Haskell, but these systems are implemented as libraries, not baked into the language (which can have advantages and disadvantages).

Let me tell you what I'm worried about with effects systems: One of the smartest people I know of has a library called Eff https://github.com/hasura/eff that efficiently implements effects through some modifications to GHC. The thing is, she's pretty much stopped working on because she found some really nasty semantic edge-cases that she couldn't resolve to her satisfaction. (I don't understand the problems well enough to describe them, and I think they're specific to lazy languages, but it has left me cautious about the effect model in general.)

eff was supposed to solve (some of) the above problems, but it's stalled now.

Why do you need a GUI library, if you can write your application using extensible effects frameworks, just choose any and enjoy!

I would argue that the fact that not all monads compose is a feature, not a bug, in that not all effects are compatible. Citing from in-other-words: