[cousin_it]

Yes, I agree. But that difference is irrelevant and distracting to people who just want to do effectful programming. A computation that's allowed to call handlers A and B should be always convertable to a computation that can call handlers B and A. There's no point in using a more general abstraction (monads) that doesn't give you the operations you need.

[dllthomas]

This is handwavy and wrong.

Imagine we have two effects that need handling. One is "failure" - terminating the computation and propagating the fact of failure. The other is "emit", producing some value for an external process.

If I combine these two, the question arises as to the behavior of "emit 3; fail" - does it emit or bury the 3? Depending on the circumstance, either could be useful, and it's a tremendous difference that is neither irrelevant nor distracting.

[cousin_it]

If I understand algebraic effects correctly, the computation "emit 3; fail" might emit or bury the 3 (or do something even more strange) depending on which effect handlers you pass to it. Keeping effect handlers outside of computations is what allows for commutativity etc.

[dllthomas]

I am not objecting to algebraic effects; I am objecting to your calling the different orderings "irrelevant and distracting." It is a vitally important detail that can easily make the difference between correct and broken code. When a code snippet can be written making no assumptions about ordering, exposing it as polymorphic with respect to ordering is great. When it must rely on a particular ordering, pretending it doesn't will bite you.