Well, I gave the example of a logging effect above. In the post there’s also an example of a key-value store effect. What’s missing from these examples exactly?

All of these effects have simple operations (get and put for store, the `write` operation for the logging effect, etc.) These are all normal operations in your language: they just return values, like normal, and the laws that govern them are equivalent to the laws of any other algebra.

Elsewhere you mentioned Boolean algebra, and that people shouldn’t confuse that with algebraic effects: Boolean algebra can absolutely be another example of an algebraic effect! The operations are the Boolean operations (call them whatever you like, + or * or whatever), and the laws are the usual laws.

The point of algebraic effects is in noticing that traditional effects (logging, state, exceptions) can be thought of as algebraic the same way as Boolean algebras or monoids.

If you’re looking for an implementation, there are lots of implementations available in Haskell and other languages. However, to understand those you’d really already have to have a good understanding of the topic first, and then you’d also need to be comfortable with Haskell syntax (and probably free monads as well). I think that the paper really gives the best introduction to the topic, unfortunately there’s no way to simplify it much further.

I don't think I mentioned boolean algebra? I responded to someone else mentioning it. My problem there is still that you are going to be taught how to operate over boolean values using an algebraic construction. (Looking, I think that is accurate. Apologies if I am the one that brought it up somewhere, I don't remember that.)

Which, fair that may help some people. I just feel that this is akin to asking for people to understand algebraic effects using basic algebra from middle school. In basic algebra practices, you lean heavily on the basic operations applied to reals and see how to manipulate equations to discover both solutions and other statements about the equations. (Advanced students will eventually extend to imaginary numbers, but I don't think that changes this statement?)

Similarly, with algebraic datatypes, you learn what it means to combine the domains of types together. Since it is an algebra, you learn this in terms of the basic operations. Hence SumTypes and ProductTypes. My assertion there is that this is hard for people because they don't actually do the algebra on the domains. And, by "they" I largely mean the software that they write.

So, with algebraic effects, I would expect that this is about the ways that effects can be combined using basic algebra tools. But what is it that you are combining? In the types, you were combining domains for analysis. In effects, I'd expect that you are combining whatever it is an effect is. You seem to be saying that an effect is a standard value? But, that seems at odds with the definitions that distinguish "pure" functions from those that have "effects" being defined by things that they cause to happen.

It doesn't help that we typically talk about things that we want to preserve some property on. It isn't enough to say "writes to stderr", we want to know that it does so without clobbering someone else currently writing to the same spot. At the least, we probably want to know that it line buffers output in such a way that that is preserved.

So, when asking for an example, I'm hunting for something to meet me somewhere in the middle. Sucks that this commonly comes down to "writes to a logger."