What Color Is Your Monad

Maybe you already knew about this and is still asking, though?

    Ndet<Io<Exn<T>>>
    Ndet<Exn<Io<T>>>
    Io<Ndet<Exn<T>>>
    Io<Exn<Ndet<T>>>
    Exn<Ndet<Io<T>>>
    Exn<Io<Ndet<T>>>

By using effect sets, we can extract fine-grained over the effects in a program at a given point, without having to worry how effects are assembled and dispatched (indeed, in effect-based languages, most of these effects can be statically inferred).

Most functional languages do model these effects using monads, and provide powerful transformations to ensure that the ordering of encapsulation doesn't matter. The composition is explicit, but at least it's a lot easier than languages that don't support monads.

Writing a language is as much about choosing limitations as it is features. Going from the untyped to the typed lambda calculus limits the number of programs that can be expressed (at least until dependent types get involved), but makes it easier to reason about the remaining set of programs. Monads are more powerful, but harder to reason about. A language without monads that doesn't compromise on an effect system is a pretty great language in my book.

This definitely is overkill, I just wanted to illustrate that it was possible. You're correct: usually, a generic effect indicates you're passing a closure to the function that may execute additional effects:

    fn filter_users<F>(
        cond: fn<F>(User) ->{F} Bool,
        users: List<User>
    ) ->{F} List<User>

In the case where there are no external effects, F will be inferred to be the union of the empty set and whatever effects are used in the body of the function. Some languages are actually pretty strict about this, and explicitly declaring an empty effect set may mark the function as pure, which may not be what you want!

Effect sets don't prevent you from using monadic wrappers when appropriate. In combination with delimited continuations, effects allow languages to reify effectful computation in an understandable and computationally efficient manner.

> You have errors and nondeterminism? Well, do errors cause rollback or abort the entire thing?

It depends on how the handler is implemented, meaning the user of a function who is calling an effect has the ability to override the way the effect is performed.

Traditional exceptions, exceptions that resume, or computations that can be canceled can all be implemented using an effect system.

There are a lot of papers on Algebraic effects, but the best way to convince you of their utility is to look into the literature yourself. The koka language guide, 'Algebraic effects for the rest of us' and (later) oleg's work are good starting points.

> or pretend that ordering does not matter when it clearly does.

Ordering does matter; effects are performed in the order they are produced.

There are a few downsides, and they fall into four categories:

1. Effect sets get rid of external effect ordering. If you have an effect set {A, B}, you can't know if A happens before B without reading the code. Same issue as monad transformers.

2. Handlers are sometimes hard to reason about. A handler is essentially a fancy try/catch block for resumable exceptions. And construct that introduces a non-local control-flow dependency can be hard to reason about. (This is especially true as a compiler writer, haha)

3. The syntax is hard. I'm serious: how do you even represent an effect set? I went with a unison-like approach in my post, but this breaks down in an unsatisfactory if you make some other decisions. Also, what is an effect set in relation to your languages type system? Is it just a fancy enum? Should we allow other sets of types? What does an effect set mean on its own?

4. Lack of idioms and libraries. Result<T, E> is well-established - what idioms arise when programming with effects? In my experience, effects are rarely explicit, and are only used if you're trying to implement something using non-trivial control flow, like generators or cancellation.

    <exn, console, e>

In the case of needing a correlation id, this is a great use case for effects! First we declare an effect type:

    effect correlation_id
      ctl id(): int

    with ctl id()
      resume(7)

    log("nice!")

Then any functions that are called in this scope, when they call 'id', will receive 7:

    fun log(message: string): <console, correlation_id> () {
      println(id())
      println(message)
    }

    7
    nice!

I usually translate in my head to side-effect thingies. Much easier. So, Maybe<T> is short hand for it could be there, or not, you'd have to check. Same with Result<T>. Or Optional<T>. Or Future<T>. It's nicer than having null as a default value and then triggering a null pointer exception because you forgot to check but a bit less readable if you start wrapping them.

But if you have a language with nullable types, like Kotlin, you can your cake and eat it. For example, you can have functions like isNullOrBlank defined on nullable strings (String?) which don't throw a null pointer exception if you call them on a null value. Just syntactic sugar for the common use case.

Likewise, Kotlin has more syntactic sugar that functional programming types would frown upon that is actually nice to use. Like suspend functions that you can use to write asynchronous programs that almost look like they are normal synchronous ones. With proper support for cancelled co-routines, error handling, threading, reactive programming, etc. Yes, they're colored functions. But, colored functions are nice and easy to work with. My compiler will tell me off when I do it wrong.

Is it all monads under the hood or just a pragmatic language?

In fact overly general abstractions are an anti pattern in practical software development, at least in my opinion. Any problem can be successfully extrapolated to a more general case, that doesn't mean it's worth doing it.

             RankNTypes
           , TypeFamilies
           , FunctionalDependencies
           , FlexibleInstances
           , UndecidableInstances
           , MultiParamTypeClasses

Of course, the null pointer can still exist in Safe Rust, but since you can't de-reference it I think it's fine to say Safe Rust is "close enough" to count.

Rust, at least, requires that this happens in unsafe code, but for sure, a bug in unsafe code can lead to null references. We are doing noobs a disservice if we claim otherwise.

* https://eed3si9n.com/learning-scalaz/Applicative.html

I know the Haskell operators, but the Idris syntax are new to me.

BTW * has to be escaped with a \.