The issues with effect systems

[atravers]

Has the “asthetic similarity” between effect systems and checked exceptions been noticed by anyone else?

If the terminology is changed from “effect system” to “checked effects”, then the experience with compile-time checking of exceptions seems relevant - to to paraphrase Anders Hejlsberg from this article:

• Let’s start with versioning, because the issues are pretty easy to see there. Let’s say I create a [definition] foo that declares it [uses effects] A, B, and C. In version two of foo, I want to add a bunch of features, and now foo might [use effect] D. It is a breaking change for me to add D to the [type signature] of that [definition], because [any] existing caller of that [definition] will almost certainly [need its type signature changed].

  Adding a new [effect] to a [type signature] in a new version breaks client code. […]

• The scalability issue is somewhat related to the versionability issue. In the small, checked [effects] are very enticing. With a little example, you can show that you’ve actually checked that you [dealt with the effect], and isn’t that great? Well, that’s fine when you’re just calling one API. The trouble begins when you start building big systems where you’re talking to four or five different subsystems. Each subsystem [relies on] four to ten [effects]. Now, each time you walk up the ladder of aggregation, you have this exponential hierarchy below you of [effects] you have to deal with. You end up having to declare 40 [effects] that you might [rely on]. And once you aggregate that with another subsystem you’ve got 80 [effects] in your [type signature]. It just balloons out of control.

These could be why some people prefer just using IO actions with IORefs, etc over checked effects effect systems - due to the monadic interface, I/O by itself is already considered rather invasive by more than a few…