What Is Algebraic About Algebraic Effects?
Posted3 months agoActive3 months ago
interjectedfuture.comTechstory
calmpositive
Debate
40/100
Programming LanguagesAlgebraic EffectsFunctional Programming
Key topics
Programming Languages
Algebraic Effects
Functional Programming
The article explores the concept of algebraic effects in programming, and the discussion revolves around understanding the 'algebraic' aspect, drawing parallels with algebraic data types and monad algebras.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
43m
Peak period
29
0-12h
Avg / period
8.3
Comment distribution33 data points
Loading chart...
Based on 33 loaded comments
Key moments
- 01Story posted
Sep 22, 2025 at 10:30 AM EDT
3 months ago
Step 01 - 02First comment
Sep 22, 2025 at 11:12 AM EDT
43m after posting
Step 02 - 03Peak activity
29 comments in 0-12h
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 27, 2025 at 7:04 PM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45333978Type: storyLast synced: 11/20/2025, 5:54:29 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
This is in contrast to doing operations on either the "types" or the "effects" that are happening during code. So, you have to show people what are the equivalent of + and * in types and effects to show them how these can be thought of algebraically.
I still think this would be easier if a type system was made that let you use + and * in defining something. It would give an obvious path to seeing how things relate to algebra. Would almost certainly make some things harder, of course. Maybe it would be a good worksheet asking questions about stuff?
The big underline, though, is getting people to realize what algebra there is is not on the values that your code represents. It is treating something else as the value for the algebra.
That is, I think this is what you are saying? That it wouldn't be hard to show that an Optional<String> is the same as a variable that is (String + None) or some such. But having Either<String, String> kills this, since there is no way to distinguish the left and right String types, there. Now, if you forced it to be Either<ErrorString, ResponseString>, that can work. And that nicely explains why you have to tag the types to be distinguishable from each other.
Then, you are going to move to discussing the algebra over types and effects. In such a way that you don't actually use + or * to represent the operations.
Obviously, the above definition is a bit contrived, but that's my understanding of why these things are called 'algebraic' effects. 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.
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.
> 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.
For two, though, the whole idea is how to compose the "value" of different effects together? 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. It will be a meta-value about some state represented by the program.
Is that not the case? If my use of the word "value" there is confusing things, I'm open to using some other words. My point is largely that the "value" of concern in effect systems is not the same as the value of a variable as people are used to reasoning. You are specifically meta-reasoning about the state of the program in ways that may not be represented by an explicit value of the program.
Not that that alone is unheard of. If you asked people to tell you the program counter of a function, they would largely get what you mean. Even if it is not something that is represented in the values of the program, itself.
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:
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).
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.
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.
If you have examples you recommend, I'd be game to look over them.
What is a first class "value" that is referenced in algebraic effects?
My understanding for effects was more like "writes to stdout" and such. Probably better to have "opens a stream," "writes to an open stream," and "closes a stream." The algebra that I typically see is to show that you can combine some of these in such a way to either highlight a bug, or to help prevent them.
I got this because many effects typically go through hurdles to find a way to let you log to stderr without it polluting your entire effects system.
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.
Almost certainly a lack of formal education in maths higher level than simple calculus, but "unions" and "interface" or whatever the latter might be called in the language of choice is just so much easier to remember.
[0]: https://aog.makie.org/stable/#Example
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.
Author here! Open to learning. Can you expand on this? What is algebraic referring to in a technical sense?
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.
The _algebra_ you learn in school is elementary algebra, using variables.
In modern math, _algebra_ or _modern_ algebra or _abstract_algebra, is the study of structures over sets with defined operations on the elements of that set.
ADTs are an example of an algebraic structure, specifically called one that converts non-trivial semantic (runtime) properties to trivial ones (T/F).
This post is dealing with the structure in another way.
If you understand magmas, monoids, etc.. that can be helpful.
But the lay description I find useful is the algebra is what _arises_ from that defined set domain and operations.
The key point is studying the structure, which is the algebraic structure, or the algebra. It is basically what pops out, not what you start with, although that is flawed.
Almost all modern math will use that _modern_ meaning of algebra.
I actually wish we taught more of this math early on[0]. Children seem to be quick to grasp many of the fundamentals of important structures like groups, fields, and algebras. I find that many of these concepts have fundamentally shifted how I think and can be used on a daily basis, without the need of writing formulas or using formal semantics.
It's odd that it takes getting up upper division undergraduate education in math (or sometimes from neighboring fields) to learn what the field is even fundamentally about. It's akin to teaching people that programming by teaching people how to use a word editor. It's such a narrow aspect and no surprise so many are so fundamentally confused.
[0] I'm unconvinced the "new maths" programs were a complete failure. Just because we didn't get it right on the first attempt doesn't mean we should have thrown the baby out with the bath water.
At least the monad algeba gives a nice hint on how to view algbraic effects. Instead of using a monad so you can raise an exception
You use an E-algebra (h :: E a -> a) instead to create a function that takes both an input and an exception handler to produce an output The canonical example being something like And a simple example of a handler being something like a default value With the advantage of course that given a handler you can be much more flexible in how you handle exceptions and where. You're not limited to just returning early, you can handle the exception and carry on.5 more comments available on Hacker News