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.
taeric•2h ago
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.
andrewflnr•1h ago
taeric•1h ago
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.
rixed•3m ago
daxfohl•1h ago
taeric•1h ago
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.
oisdk•40m ago
> 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.
taeric•18m ago
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.
zdragnar•12m ago
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.