By the way, nondeterminism is not the only difference between the two.

It is useful for understanding laziness and some interesting theoretical tools for traversing data structures, though. For a more in-depth look at the idea of circular programs for traversal, Bird's paper (linked in the post, https://link.springer.com/article/10.1007/BF00264249) is a good start.

My overall point was that I felt your original comment was a little confused about algebraic effects. You seemed to think that the "algebra" in "algebraic effects" didn't refer to algebraic operations on normal values, which is incorrect. The basic middle-school algebra of a ring (+, *, etc., with all of the normal laws) does indeed give rise to an algebraic effect, and code that uses that effect can just be normal code like `x = 2 * y`. The "effect" here is the "ring" effect.

However, I don't think that this discussion is that productive. If you want to understand algebraic effects, unfortunately there is no substitute for just reading through the fundamental literature (like the paper I linked). I would love to be able to give you a short, easy-to-understand example that explains all the ideas in a few lines, but the concept just isn't that simple.

I see this a lot on this forum in particular: people like to develop a vague intuition for something rather than really understanding the concept properly, but almost always their "intuition" is very inaccurate, and they understand the thing less well than they think they do. Then, they try and teach others the concept, and those learners are even more misled.

----------------------------------------------------------------------

I will try and point out some misconceptions in your last comment here, but again I will caution that I don't think you will be able to fully understand the topic just by reading these comments.

> So, with algebraic effects, I would expect that this is about the ways that effects can be combined using basic algebra tools.

I understand, but that is not what algebraic effects is about.

The "algebra" in algebraic effects doesn't refer to an algebra for combining effects, it refers to algebras like monoid etc., and you get an effect for any particular algebra.

> In effects, I'd expect that you are combining whatever it is an effect is.

This is incorrect. First, there are algebras that have no "combining" at all, and second, the algebras involved are just the normal algebras you're already familiar with, like the boolean algebra etc.

> 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.

Yes, an effect is a standard value. And yes, we often want to distinguish pure functions from effectful ones. (By the way, this does not mean that effectful functions are somehow not standard values)

However, in an algebraic effect the algebra does not combine effects.

> 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.

I mean, obviously if the write is going to be performed concurrently you'll need more guarantees.

I included one law that might be important, but you could easily add more. That doesn't change the core concept.

> 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."

I'm not sure what you mean by the "middle"—middle between what two extremes? I picked the writing to a logger example because it was simple, and showed a simple law. The key-value store in the post is a little more complex, and involves a few more laws. In the paper there's even more examples: I/O etc. You have a lot of examples available to you!

This is a misconception. Algebraic effects are not algebraic because they come from algebraic data types, the two features are completely independent (you can have algebraic effects without algebraic data types and vice versa).

> It's not that ConsoleOutput and ConsoleInput (however you define that using + or *) are magically 'composable' just because they're both algebraic... for that composition you need extra rules (however you specify that) because effects don't (in general) compose.

Actually, if you have two algebraic effects they can automatically compose. And this is a consequence of them both being algebraic. It's just that an algebraic effect is unrelated to an algebraic data type.

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.

You can also form an algebra from logging. One operation might be “write to stdout”. And then a law might be `write x; write y = write (x ++ y)` where ++ is string concatenation.

This is the algebra, the algebra isn’t for combining effects at all. (Yes, you can combine algebraic effects, and the fact that they’re algebraic does help, but that’s for technical reasons that aren’t relevant)

The paper I linked in another comment has a good overview of the topic. It’s really not the kind of thing you can understand from reading a few comments, and the paper is well-written and goes over all of the main points from a pretty basic starting point.

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.

In the effects literature, you often also see the definition that an operation (of an effect) is "algebraic" if the operation commutes with `>>=`. This definition is actually the same as the one above, just stated in a different way.

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

> 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).

> The big underline, though, is getting people to realize what algebra there is is not on the values that your code represents.

This is not correct. In the case of algebraic effects, the algebra is absolutely value-level.

While I like the above blog post, I don't think that it will be very useful to people trying to understand algebraic effects. I see a lot of explainers like this one that shy away from some of the more gnarly-looking maths terms in an effort to appear more approachable, but as a result they can end up giving imprecise or vague definitions. When coupled with some subtle mistakes I think it can leave beginners more confused than helped (for instance, this author seems to conflate a few different notions of "composition", and they seem to think that the presence of equations makes an effect algebraic, which isn't really what the term "algebraic" is referring to in a technical sense).

The paper I linked above is not easy, and it would probably take at least a few hours to understand, but that's because it takes about that long to understand the material.

Lean is also a programming language with proof support. It is very much in the same category as F* in this regard, and not in the same category as Coq (Rocq).

> There's limited interest in it though because most of those things simply have no profit potential

This is not true. There is a lot of interest in the Keto diet, it has been well-studied and has uses in treating epilepsy. The reason it's not prescribed more generally is because of those studies, which show it doesn't work. Not everything is a conspiracy.

There are countless cases of shoddy care from doctors. The existence of crappy doctors does not mean keto is effective.

> Modern medicine is NOT patient focused: it's pharma focused.

Again, the existence of bad incentives in medicine/corruption is not evidence of keto working.

> And who do you think sponsors most of those "medicine journal" studies?

There are serious, good-faith criticisms of modern medicine to be made. Blindly saying it's all nonsense, and instead you should do a juice cleanse with keto instead of chemo, is not a serious good-faith criticism.

> if thousands of people healed their diseases which the "modern medicine" completely fails to heal using the keto diet

This has not happened. Keto has not healed thousands of peoples' cancer. There is no evidence (and I mean real evidence, not a youtube video or podcast recounting an anecdote) of keto being effective at curing cancer.

By "not mainstream approved" you mean it's largely discredited and confined to quacks and charlatans online. Outside of its one legitimate use—very specific cases of epilepsy—no serious medical organisation endorses keto for the general population or cancer patients.

The third video you link is of a person who thinks that they cured their cancer with, among other things, juicing, breathwork, "positive mindset", and keto. This is nonsense.

> despite people healing conditions on it that no modern medicine could

If it worked, it would become "modern medicine". The reason it's not accepted in the mainstream is that it has failed every basic test of efficacy. The reason that you will find it promoted primarily on youtube and not in major medical journals is that the youtube audience is less well-equipped to spot it as snake-oil.

In the article itself, the line:

> As it happens the computation will need the value of b before that of a. If this is a problem, we can write the definition of root1 as

Is actually quite interesting: the problem being described there is almost identical to one of the problems that Haskell had with I/O, which motivated the introduction of monads.

I think that claim is pretty uncontroversial, which is why I didn't provide "evidence" for it, and also I get the sense that I'd be wasting my time in arguing with you about it when you throw out silly pedantries like "oh well dorne is based on palestine".

No. Westeros is based on medieval Europe, culturally, politically, and historically. Obviously it's fiction, well done on spotting that, but it's a fictionalised version of medieval Europe.

> Undeniably? Based on...what evidence?

I'm sorry, do I have to provide you with evidence that media impacts people's perception of things?