[oisdk]

> For one, if algebraic isn't aiming at the ideas in an algebra, then they absolutely should be using a different name.

Algebraic effects are certainly algebraic, they're just not directly related to algebraic data types. Both ideas are using "algebraic" at different levels, and I think trying to understand algebraic effects by referencing algebraic data types will be more confusing than helpful.

> My point is that the "value" is not the written value of a variable in ways that people are used to working with in their program.

I'm saying that (in algebraic effects) the "value" in question is precisely a normal variable that people are used to working with in programming languages. It is not a type-level value, which is the kind of value in question when we're talking about algebraic data types.

For example, if we take Groups (the algebra referenced in the post), we have a binary operation (that we might call +) along with a few other operations. We could write a piece of code like the following:

    x = y + z

The "group" in question here could absolutely be an algebraic effect. And the line of code above could be implemented using algebraic effects, and interpreted using an algebraic effect handler. You don't even need types, if you didn't want them.

> For two, though, the whole idea is how to compose the "value" of different effects together?

No, not really.

Yes, algebraic effects compose well. But so do other effects systems and abstractions (applicatives, etc.). The fact that the effects compose is not what makes them algebraic, it's a consequence of it.

I don't think I can give a proper explanation in a comment, but I would point you to the paper I linked in another comment (https://arxiv.org/abs/1807.05923).

[taeric]

I'm not positive on what you are aiming at. I'd assume "algebraic effects" are to talk about performing algebra on the effects. That is, you are specifically going to talk about how different things combine effects, preferably in ways that honor + and * that we are used to.

If you are just pointing out that this is not, necessarily, "type" related. Agreed. Apologies if I mislead there. I was highlighting that algebraic data types has a similar problem. I did not mean to imply that these were the same topic.

My point is simply that there is no value in the program that says an effect has or has not completed. This is why I compare it to stepping through the program. The "line of code" that is active in executing code is not a first class value in your program. It is very much there, of course. But it is not a value of the program.

[oisdk]

> I'd assume "algebraic effects" are to talk about performing algebra on the effects. That is, you are specifically going to talk about how different things combine effects

This is a misconception. The "algebra" does not refer to an algebra of effects, or combining effects in any way.

It's more like it's the other way around: "algebraic effects" are effects generated from algebras. These algebras are precisely-defined mathematical objects (like groups, monoids, etc.), so you have an "effect" that corresponds to monoids, an "effect" that corresponds to groups, and so on.

> My point is simply that there is no value in the program that says an effect has or has not completed. This is why I compare it to stepping through the program. The "line of code" that is active in executing code is not a first class value in your program.

I know: I'm trying to say that the "algebra" of "algebraic effects" do refer to first-class values. The + and * from other algebraic operations are the algebraic operations you might use for an algebraic effect.