None of the stuff discussed in the article has anything to do with effects. The author is just misusing standard terminology. In fact, the author also seems to confuse polymorphism with generics. In fact he seems to confuse abstraction with generics as well.
If there was any idea here, it was lost in a sea of confusion.
That seems unfair, I did not get the impression that the author was confused about any of the terminology. Perhaps it was written for a broader audience appeal (using generics when meaning polymorphism seems like a reasonable thing to do to me). I am not a type theorist, so maybe I’m not appreciating the subtle differences in definitions.
What do you mean the article had nothing to do with effects? I’ll admit, my understanding of effects comes primarily from algebraic effects, and I wouldn’t say I have a lot of depth in it, but I’m curious what the article is talking about then.
I’m all for calling out poorly written articles (I mean, see some of my comments), but please provide more evidence. I went into this thinking it was going to be garbage, but felt like it was well written and had interesting ideas.
No, the GP is right and the article has almost nothing to do with effects. The article says:
Rust has continuously evolved since version 1.0 was released in 2015. We’ve added major features such as the try operator (?), const generics, generic associated types (GATs), and of course: async/.await. Out of those four features, three are what can be considered to be “effects”. And though we’ve been working on them for a long time, they are all still very much in-progress.
…
But out of everything which can lead to API duplication, effects are probably one of the biggest ones. When I talk about effects in Rust, what I mean is certain keywords such as async/.await and const; but also ?, and types such as Result, and Option. All of these have a deep, semantic connection to the language, and changes the meaning of our code in ways that other keywords and types don’t.
const is not an effect. ?, Result, and Option are not effects.
Algebraic Effect Types: which are semantic notations on functions and contexts that grant a permission to do something. … In this talk we’ll only be discussing effect types.
c.f. Gifford (1987):
This effect system is part of a ‘kinded’ type system with three base kinds: types, which describe the value that an expression may return; effects, which describe the side-effects that an expression may have…
Advanced Topics in Types and Programming Languages says:
Meanwhile, algebraic effects [Bauer and Pretnar 2015; Plotkin and Power 2003; Plotkin and Pretnar 2013] have emerged as a powerful alternative that allows programmers to define their own control effects. They subsume a wide range of features including exceptions, generators, and async/await.”
Weirdly enough, even the initial blog post of the Keyword Generics WG (which I assume became the Effects Initiative?) is clearer:
Q: Are you building an effect system?
The short answer is: kind of, but not really. “Effect systems” or “algebraic effect systems” generally have a lot of surface area. A common example of what effects allow you to do is implement your own try/catch mechanism. What we’re working on is intentionally limited to built-in keywords only, and wouldn’t allow you to implement anything like that at all.
What we do share with effect systems is that we’re integrating modifier keywords more directly into the type system. Modifier keywords like async are often referred to as “effects”, so being able to be conditional over them in composable ways effectively gives us an “effect algebra”. But that’s very different from “generalized effect systems” in other languages.
I think the author has confused generic types or monads with effects. The only thing in the article that is related to effects is async/await, but their proposed solution is not an effect system. Charitably they are trying to be poetic and lump separate things under one term.
Thanks for providing context for the confusion; I’m not an expert, as I’m sure many on this site are, and by dismissing without any follow-up reading or explanation creates in-groups and out-groups. I’m all for disagreement, but for the goal of education.
To me it feels like the term “effect” is somewhat ambiguous, whereas “effect system” is more concrete (generally referring to algebraic effects). Are there any effect systems which are not specifically algebraic effect systems?
To me it feels like the term “effect” is somewhat ambiguous, whereas “effect system” is more concrete (generally referring to algebraic effects).
No, the term “effect” is no more ambiguous than “effect system.”
Are there any effect systems which are not specifically algebraic effect systems?
Yes, in my comment I mentioned regions. From Advanced Topics in Types and Programming Languages, Chapter 3, Effect Types and Region-Based Memory Management:
The basic effect type judgment is Γ ⊢ t :φ T where φ is an effect expression (henceforth simply called effect) and φT is an effect type or type and effect. The judgment should be read informally as “Under the assumptions Γ , the evaluation of t may have the observable effect φ, and it eventually yields a value of type T, if any.” For program analysis purposes observable may also be understood as interesting. When an evaluation has no observable effect, we say it has the empty effect, written ∅, and ∅T is abbreviated to T.
Here is how effects relate to regions:
An effect is a finite set of region variables. Note that it must not contain •. A judgment Γ ⊢ t :φ T is intended to express that, assuming the free variables of t are bound to values of types according to Γ , the regions that t accesses during evaluation are included in φ and the result of the evaluation has type T if it terminates.
…
Region-based memory management uses explicit instructions for the allocation and deallocation of memory, but the safety of the explicit deallocations is guaranteed by a type system, and in some cases a compile-time analysis called “region inference” (§3.6) can insert the allocation and deallocation instructions automatically
There is no connection between effects systems used for region-based memory management and async/await, const, ?, Result, or Option.
This is as much as I’m willing to type out. As Brandolini’s law states:
The amount of energy needed to refute bullshit is an order of magnitude bigger than that needed to produce it.
I don’t feel I know enough PLT to defend this article as a whole, but Rust’s const is similar in use to Koka’s pure, which Koka calls an “effect type” or just “effect”.
Can you elaborate on the terminology problems in the article?
Looking through the papers, it seems like there is a reasonable semantic interpretation of the effects (and their implicit handlers) as listed in the article.
Granted, the article doesn’t address the type system, but it seems like many papers and research systems don’t either?
There are no user-specifiable handlers, but the article discusses that.
The use of “generic” seems to refer to parametric polymorphism (which seems in line with typical use), once including row-polymorphism (still seems fine). It always seems to refer to methods of generic programming. It’s true that generic programming/bounded parametric polymorphism can abstract over various things, but I didn’t see other uses of “generic” that suggested a conflation with the general concept of abstraction, such as encapsulation.
I’ve recently been getting into effects and the exciting possibilities around “color blind” and moving what we think of as language features (exceptions, coroutines, etc) into something that user code could create using effects.
I really didn’t understand much about how that related to the article. They touched on solving one common problem (async/sync) but I didn’t even recognize their solution as involving effects.
At this point I’m confused but maybe there’s more than one thing called effects? There was no “perform” operation anywhere or handlerish construction.
Rust is not OO, it doesn’t have polymorphism as such (unless I’m misunderstanding how you’re using it). It has traits and lincould see how that’s viewed as a kind of polymorphism, but it’s often used through generic bounds.
I’m new to the term “effect” in this context the author lists other languages as prior art Koka, Eff, and Frank. How would you typically expect it to be used and how would you describe the impact of these features that yosh is talking about on the type system?
Polymorphism has nothing to do with OOP, it was introduced in ML in 1975[1], a functional language. And it was previously discovered in mathematics in 1969[2].
Rust uses an extension of a Hindley–Milner type system, which is precisely the type system where parametric polymorphism was invented. Rust also has ad-hoc polymorphism, of course.
Koka, Eff, and Frank have algebraic effect and effect systems, indeed, and they have nothing in common with what is being discussed in the article.
I wish Rust had an effect system based on algebraic effects and handlers, but it doesn’t, and the blog post doesn’t mention anything happening in that direction at all. Quite the opposite.
If I take the most generous interpretation possible of the article, it talks about modalities[3] and mode polymorphism, but even that is a stretch (because the author confuses types with modalities). It certainly does not talk about effects.
Shameless self promotion that my hobby programming language that targets Rust has an effect system and effect handlers –> https://letlang.dev
In the runtime, every block of code is a generator (using genawaiter since it’s not yet stable). Whenever an exception is thrown (non resumable effect) or an effect is performed, the generator yields an Interrupt enum (with 2 variants, one for the exception, one for the effect). So it’s definitely possible to implement effect systems as a library thing, though it would be quite intrusive.
FYI: If I’m not mistaken, generators are what is used to implement Rust async/await, it’s just not exposed yet as a public API for some reason.
None of the stuff discussed in the article has anything to do with effects. The author is just misusing standard terminology. In fact, the author also seems to confuse polymorphism with generics. In fact he seems to confuse abstraction with generics as well.
If there was any idea here, it was lost in a sea of confusion.
That seems unfair, I did not get the impression that the author was confused about any of the terminology. Perhaps it was written for a broader audience appeal (using generics when meaning polymorphism seems like a reasonable thing to do to me). I am not a type theorist, so maybe I’m not appreciating the subtle differences in definitions.
What do you mean the article had nothing to do with effects? I’ll admit, my understanding of effects comes primarily from algebraic effects, and I wouldn’t say I have a lot of depth in it, but I’m curious what the article is talking about then.
I’m all for calling out poorly written articles (I mean, see some of my comments), but please provide more evidence. I went into this thinking it was going to be garbage, but felt like it was well written and had interesting ideas.
No, the GP is right and the article has almost nothing to do with effects. The article says:
constis not an effect.?,Result, andOptionare not effects.See 2.1 Instances and operations in this paper on Eff for algebraic effects with handlers. See Gifford et al. (1987) and Talpin and Jouvelot (1992) as referenced in Types and Programming Languages for systems for tracking effects on regions.
The article claims that:
c.f. Gifford (1987):
Advanced Topics in Types and Programming Languages says:
Handling Bidirectional Control Flow says:
Weirdly enough, even the initial blog post of the Keyword Generics WG (which I assume became the Effects Initiative?) is clearer:
I think the author has confused generic types or monads with effects. The only thing in the article that is related to effects is async/await, but their proposed solution is not an effect system. Charitably they are trying to be poetic and lump separate things under one term.
Thanks for providing context for the confusion; I’m not an expert, as I’m sure many on this site are, and by dismissing without any follow-up reading or explanation creates in-groups and out-groups. I’m all for disagreement, but for the goal of education.
To me it feels like the term “effect” is somewhat ambiguous, whereas “effect system” is more concrete (generally referring to algebraic effects). Are there any effect systems which are not specifically algebraic effect systems?
No, the term “effect” is no more ambiguous than “effect system.”
Yes, in my comment I mentioned regions. From Advanced Topics in Types and Programming Languages, Chapter 3, Effect Types and Region-Based Memory Management:
Here is how effects relate to regions:
There is no connection between effects systems used for region-based memory management and
async/await,const,?,Result, orOption.This is as much as I’m willing to type out. As Brandolini’s law states:
I don’t feel I know enough PLT to defend this article as a whole, but Rust’s
constis similar in use to Koka’spure, which Koka calls an “effect type” or just “effect”.Can you elaborate on the terminology problems in the article?
I’ve recently been getting into effects and the exciting possibilities around “color blind” and moving what we think of as language features (exceptions, coroutines, etc) into something that user code could create using effects.
I really didn’t understand much about how that related to the article. They touched on solving one common problem (async/sync) but I didn’t even recognize their solution as involving effects.
At this point I’m confused but maybe there’s more than one thing called effects? There was no “perform” operation anywhere or handlerish construction.
No, it is the author of the article who is confused, not you! You’re totally right!
Rust is not OO, it doesn’t have polymorphism as such (unless I’m misunderstanding how you’re using it). It has traits and lincould see how that’s viewed as a kind of polymorphism, but it’s often used through generic bounds.
I’m new to the term “effect” in this context the author lists other languages as prior art Koka, Eff, and Frank. How would you typically expect it to be used and how would you describe the impact of these features that yosh is talking about on the type system?
Polymorphism has nothing to do with OOP, it was introduced in ML in 1975[1], a functional language. And it was previously discovered in mathematics in 1969[2].
Rust uses an extension of a Hindley–Milner type system, which is precisely the type system where parametric polymorphism was invented. Rust also has ad-hoc polymorphism, of course.
Koka, Eff, and Frank have algebraic effect and effect systems, indeed, and they have nothing in common with what is being discussed in the article.
I wish Rust had an effect system based on algebraic effects and handlers, but it doesn’t, and the blog post doesn’t mention anything happening in that direction at all. Quite the opposite.
If I take the most generous interpretation possible of the article, it talks about modalities[3] and mode polymorphism, but even that is a stretch (because the author confuses types with modalities). It certainly does not talk about effects.
[1] https://www.research.ed.ac.uk/en/publications/a-logic-for-computable-functions-with-reflexive-and-polymorphic-t
[2] https://doi.org/10.2307%2F1995158
[3] https://plato.stanford.edu/entries/logic-modal/
Shameless self promotion that my hobby programming language that targets Rust has an effect system and effect handlers –> https://letlang.dev
In the runtime, every block of code is a generator (using genawaiter since it’s not yet stable). Whenever an exception is thrown (non resumable effect) or an effect is performed, the generator yields an
Interruptenum (with 2 variants, one for the exception, one for the effect). So it’s definitely possible to implement effect systems as a library thing, though it would be quite intrusive.FYI: If I’m not mistaken, generators are what is used to implement Rust async/await, it’s just not exposed yet as a public API for some reason.
Thanks for the detailed response.