Adding Algebraic Effects to Gleam

[CrowdHailer]

There are a lot of reasons to add Effect Tracking to a language like Gleam, and probably plenty of good reasons not too.

1. Tracking whether a function is async is helpful when rendering JavaScript
2. They are potentially (lot's of opinions here) less noisy than trying to get the same functional purity by using Monads, and Monad composition
3. They appears to be a consensus growing around a standard approach. Unison, Roc, Effekt, Eff, Koka all have effect types

Here is a good tutorial on effect types. This paper is good for the examples section. https://www.eff-lang.org/handlers-tutorial.pdf

A short discussion was previously had here gleam-lang/suggestions#49

I have been experimenting with effect types and here is one potential syntax

Simple Log

fn log(message) { effect Log(message) }

run {
  log("hello")
  "Done"
} handle (Log, message) {
  console.log(message)
}

// => "Done"

Gather all logs in a pure fashion

run {
  let [] = effect Log("hello")
  let [] = effect Log("world")
  "Done"
} handle (Log, message, continue) {
  let [messages, value] = continue([])
  let messages = [message, ..messages]
  #(messages, value)
} pure (value) {
  #([], value)
}

// => #(["Hello", "World"], "Done")

[lpil]

Super cool!

I am not yet convinced that effect handlers are simple enough of an API to fit in Gleam. We need to think carefully about ease of use.

Is effects tracking without handlers useful?

What Erlang code would the above example compile to?

[eashanhatti]

Is effects tracking without handlers useful?

Effect tracking and effects+handlers (algebraic effects) are actually orthogonal features. The value proposition of algebraic effects is that you can abstract away the details of an effect, with client code controlling how those effects are performed. As @CrowdHailer's example shows, you could provide an abstract Log operation which can be executed in different ways: A handler which prints those logs to the console, or another handler which collects them in a list. Without algebraic effects, the code performing logs would have to account for both these possibilities. Furthermore, this code would have to be changed every time a new logging method needs to be added.

The value proposition of effect tracking is security, as I believe you're familiar with. AFAICT the two features are conflated because almost every language with algebraic effects has effect tracking as well - OCaml is a notable counterexample, although this may have changed by now.

To directly answer the question: Yes effect tracking without handlers is useful, but for a completely different reason than algebraic effects are useful. We need to clarify exactly which feature we want - or perhaps both! - before going forward and discussing the concrete details.

What Erlang code would the above example compile to?

Typically languages with algebraic effects have to CPS-transform the program. I'm unfamiliar with the exact pros and cons of this approach, but it would at least obfuscate the Erlang output. I've been told readability of the output code is a desired feature?

However, we could probably use Erlang's native concurrency primitives instead! The body of a run would start a child process. Then...

1. Performing an effect (The effect statement in @CrowdHailer's example) would amount to sending a message to the parent process.
2. Handling an effect would amount to receiving that message in the parent process
3. Calling resume would amount to sending a message back to the child, which would be received by the effect statement

This would keep the structure of the Erlang output very similar to the original code - handlers and effects would be translated to simple sends and recieves.

I am not yet convinced that effect handlers are simple enough of an API to fit in Gleam. We need to think carefully about ease of use.

Right, they can get quite complicated. My two cents: Discarding effect tracking would decrease the learning curve of algebraic effects significantly.

[eashanhatti]

The user wouldn't be able to define effects, but we could still identify some coarse grained ones such as purity, ffi, recursion, and assertion

Ahh I see, I was under the assumption that user-defined effects would exist. Makes sense! Thanks for the clarification.

[CrowdHailer]

The discussion I was hoping to start here. Was very much related to the discussion of adding them as a language feature. As in the pseudo code I posted. Interesting to see how many things it can mean to people and worth making sure it's clear

[lpil]

I was under the assumption that user-defined effects would exist.

I think there probably is a lot of value there, but I'm always interested in exploring any minimal additions we could find value in before making big changes

[timjs]

Some time ago, when I was writing other large posts about implicit arguments for Gleam, I've been thinking about algebraic effects for Gleam too. Some thoughts:

• We're now at a stage where the basic language features and usability of the language are there, and addition of more features needs careful thought, as they probably will bite each other. I.e. implicits and effects can both serve in similar use cases, but in a completely different way.
• Having effect tracking without being able to define new effect will, in my opinion, quickly become unhelpful. It's like holding a carrot in front of developers they can't catch. The whole idea of effect tracking is that you can write programs which are modular in their effects. PureScript used to have effect tracking using rows in the old days (0.12 of 0.13 from the top of my head), but they removed it because it was of no added value. The only simple effect tracking that is useful, is probably tracking pure/impure calculations (see Flix for an example).
• Implementing efficiënt effect handling is not easy. Generated code will probably be hard to read. But as Erlang has light weight processes, I actually think that would be a very nice way to implement effect handlers. Or at least it would be interesting to research the idea of using Erlang processes for effect handlers! (Maybe I'll find a bachelor's or master's student to work on this for a thesis...)

[aflatter]

Having effect tracking without being able to define new effect will, in my opinion, quickly become unhelpful. It's like holding a carrot in front of developers they can't catch. The whole idea of effect tracking is that you can write programs which are modular in their effects. PureScript used to have effect tracking using rows in the old days (0.12 of 0.13 from the top of my head), but they removed it because it was of no added value. The only simple effect tracking that is useful, is probably tracking pure/impure calculations (see Flix for an example).

Jumping in without a lot of experience in PL design: I'm intrigued by the idea of content-addressed code and would like to see Gleam experiment with making pragmatic use of that. As far as I understand, content-addressing and tracking purity combined result in a nice user-facing property: the result of functions that are pure and have not changed can be easily cached even across two different versions of the code base. One of the use cases that I like is that tests can be ran once and don't have to run again unless the implementation code changes - that just sounds really useful for everyday work.

I guess it's all about trade-offs. If this property is a feature that Gleam would like to provide, then it could be useful to have effect tracking for just purity. 🤔

[inoas]

One benefit of effects tracking could be to improve compiler strictness:

pub fn main() -> Result(Int, Nil) {
  let x = 1;
  // Compiler could reject this code block:
  // because it is never bound to a variable or returned from the block
  // ...nor did it trigger any side effect
  {
    try b = Error(Nil);
    b
  }
  Ok(x)
}

p.s.: While I am far from being even an amateur on this topic, it also seems that effects of arbitrary blocks must thus be tracked and/or settable by the programmer.

[CrowdHailer]

I've recorded a discussion on how to design effect types.

https://vimeo.com/780465787