Why use an effect system?

[atravers]

@elaforge

It […] doesn’t contribute to what I see is the more interesting discussion beyond the “why at all”, namely what specific thing would be better or worse in which effect system […]

Considering how many effect systems there are in Haskell now, such a detailed comparison would rival a comparison of programming languages and their features. But a comparison could at least hint at the possibility of a more elegant solution, by exposing a recurring pattern in the majority of effect systems…

@vmchale

I’m not convinced there’s an elegant solution.

…alright, in keeping with the maxim of “not making enemies of perfect and good” (or perfect and tolerable), is there a “less inelegant” solution?

---

@daylily

To quote Alexis King:

I believe there is a ground truth that exists external to monads, transformers, and continuations. I believe an effect system should pursue it, acknowledging the advantages of adopting a model without confusing the model’s limitations for features of the terrain.

Observation - IO a is a very simple effect system:

• (page 56 of 60)

  Could we have a variant of IO that allowed exceptions but not I/O? Or I/O but not concurrency? The answer is technically, yes of course. There is a long history of research into so-called effect systems, that track what kind of effects an expression can have. […] Meanwhile I argue that a simple pure-or-impure distinction offers an excellent cost/benefit tradeoff.

  Tackling the Awkward Squad: …

• (page 27 of 55)

  Haskell’s crude effect system (the IO monad) means that almost all memory operations belong to purely functional computations, and hence, by construction, do not need to be logged.

  A History of Haskell: …

• A long time ago we had an effect system and we made pure the default (since we didn’t want people accidentally leaving it out due to sloth) and we made the impure specifier a very small and reasonable keyword: “io”.

  [rust-dev] sub-grammar for range pattern constants?

So how did the designers of SAC manage to confine nondeterminism, and separate access to it from other I/O effects? By providing nondeterminism in the form of a type (called Nondet here) whose values could be “dismantled” into two or more parts (its subvalues). This means IO a can be defined using Nondet and a simpler monadic type M a which conveys all other I/O effects - as an approximation:

type IO a = Nondet -> M a

Alternatively, Nondet can be thought of as an effect specifier (like io was in Rust):

type IO a = E_Nondet -> M a

Taking this to the limit, with numeric indices instead of names:

type IO a = E₀ -> ... -> E_∞ -> M_empty a

then M_empty a exists only to provide a sequential context for the orderly use of E₀ to E_∞:

newtype M_empty a = M_empty a

instance Monad M_empty where
   return x = pseq x (M_empty x)
   M_empty x >>= k = k x

Analogous to runIdentity for Identity a, it’s possible to obtain the result of a M_empty a value:

\ (M_empty x) -> x

and M_empty a can be as simple as:

type M_empty a = a

As for IO a, it can then be as simple as:

type IO a = E₀ -> ... -> E_∞ -> a

Or using a tuple:

type IO a = (E₀, ... E_∞) -> a

or another abstract type:

data OI -- (E₀, ... E_∞)
partOI :: OI -> (OI, OI) -- to obtain the parts (subvalues) of an OI value

type IO a = OI -> a

main :: OI -> () {- foreign export ... "hs_rts_Main_main" main :: OI -> () -}

foreign ... actionWithEffect :: ... -> OI -> ()

As for that interface, the one that even at university level, bachelor level students often struggle to comprehend:

unitIO :: a -> IO a
unitIO x = \ u -> pseq (partOI u) x

bindIO :: IO a -> (a -> IO b) -> IO b
bindIO m k = \ u -> case partOI u of
                      (u1, u2) -> case m u1 of
                                    x -> pseq x (k x u2)

Now for an edited quote by Philip Wadler:

(from page 29 of 33)

Having praised monads to the hilt, let me level one criticism. Monads tend to be an all-or-nothing proposition:

1. If you discover that you need interaction deep within your program, you must rewrite that segment to use a monad.

2. If you discover that you need two sorts of interaction, you tend to make a single monad support both sorts.

It seems to me that instead we should be able to move smoothly from:

3. no monads (no interactions)

4. to one monad (a single form of interaction)

5. to many monads (several independent forms of interactions).

How to achieve this remains a challenge for the future.

How to Declare an Imperative (1997)

1. Pass a suitable effect specifier in a existing or new parameter down to that segment.

2. A pair of effect specifiers can be used as a composite effect specifier:

   • E_{(stdin, stdout )} = (E_stdin, E_stdout)

3. …of type T_result (an ordinary effect-free Haskell expression).

4. …of type E_stdout -> T_result (an action capable of a single form of interaction).

5. …of type:

   • E_stdin -> E_stdout -> ... -> T_result

   • E_{(stdin, stdout, … )} -> T_result

   (an action capable of several forms of interaction).

---

So there is one “less inelegant” solution to the separate use of effects (but a detailed explanation of what is needed in Haskell to improve its elegance is another topic entirely) - are there any others?