Actors for free

[cognivore]

Motivation

Actor model is notoriously hard to get right in types. While developing BEAM languages, an additional temptation to make a well-typed version of OTP is an additional distraction. Quoting @lpil (who is resistant to this temptation):

There is tension here between building a type system around an actor model vs building an actor model around a type system. We’re doing the latter really.

That being said, if there is a language that has a chance to succeed in this endeavour, then it is gleam. There are two reasons for this opinion.

1. It's a pragmatic language.
2. Its compiler works via code generation.

This proposal "builds an actor model against a type system" in a way that relies on us targetting a runtime with BEAM properties, where fibers are extremely computationally cheap and are exteremly lightweight.

A neat side-effect of this proposal is that it happens to significantly improve UX of interacting with Gleam systems by allowing for named processes.

Proposal draft

Big picture

The final goal of this proposal is to create a system, where actors "just are". Meaning that if compilation succeded, then every actor that can be represented in code will be launched, be reachable and supervised.

Sketch

I have drafted code generation semantics on my Remarkable tablet, but before writing down the specification, I would like to get the sentiment from the commnity and maintainers. Thus, I present but a sketch of what should be possible shall this proposal be accepted.

/// This is a type with an 0-ary constructor.
/// We would like this to be a constructor, not a default value,
/// because it might be practical to run a side-effect in it.
type Counter {
  Ticker(count: Int)
} basis fn() { Ticks(0) }

/// This is some other type, perhaps defined in another module.
type Sound {
  Quack,
  Woof
}

/// This is the simplest message protocol type.
type Sound ! Counter {
  receive state {
    Quack -> state.count + 1
    Woof -> state.count - 10
  }
}

/// This is an abridged sketch of an SQL connection pool
type SQL {
  SQLConn(Result(Conn, ConnErr))
} basis fn() { assert Ok(_) = connect(getCredentials()) }
type PreparedStatement {
  PreparedStatement(exprs: [SQLExprOrEpsilon], values: [String])
}

/// This is an example of pool protocol type.
/// "*" means we don't care which process of type SQL shall handle our statement.
type PreparedStatement * SQL {
  assert Ok(conn) = state
  receive state {
    #(fs, vs) -> state.exec(zip(fs, vs ++ [""]) |> sql_show())
  }
}

/// A trivial user profile. Note that there is no basis for this type.
type User {
  User(id: Int)
}
type Profile {
  Profile(mood: Mood)
}
type Mood {
  Happy,
  Sad
}
type Action {
  Sabotage,
  Leave
}

/// This is an example of representation protocol type.
/// We can benefit from many long-running processes when dealing with user profiles.
/// "^" warns us of potential explosion in the amount of actors if we're not careful.
/// Indeed, when if there is a a value of type User is constructed, a corresponding
/// actor is spawned.
/// To aleviate this, representations use Continue / Stop semantics.
type Mood ^ User with Profile {
  receive _ {
    mood -> Continue(mood)
  }
}
/// We allow for partial matches on messages that are sum types.
type Action ^ User with Profile {
  receive _ {
    Leave -> Stop(Normal)
  }
}

Elaboration and an (un)educated guess on limitations of the implementation

• This proposal isn't meant to replace channels, but rather to complement them, given the capabilities of BEAM virtual machine.
• ! and * protocols produce named processes.
• ^ protocol produces one named process, with the name of the receiver type. It then can be queried for a reference to a particular receiver, which represents given value.
• Restart strategy is OFO.
• Everything is asynchronous (i.e. cast + get_state, not call).
• Parametric types can't be used as receivers for the protocol types other than "representation protocol".
• Code is generated in the module where the protocol types are defined for a given receiver.
• Functions returning protocol types (ex. f(...) -> Sound ! Counter) can be defined anywhere and then used innstead of receive clauses.

Open questions

• What are reasonable defaults for code generation?
• Can the defaults be changed (ex. type LongQuery * (SQL >= 25) to say our program needs at least 25 instances of SQL actor)?
• How open can an implementation be (i.e. can the "single integraion module" restriction be lifted)?
• Is it possible to represent dependencies between actors to account for AFO strategy?
• Given separation of operation and observing the operation, could something like circuit-breaker pattern be used for supervision instead of more naive restart strategies (more on circuit-breakers in Erlang)?
• Is it possible to provide reasonable synchronous semantics (i.e. call in addition to cast + get_state)?

[cognivore]

FTR, even though I'm a big fan of distributed Erlang and use it extensively, especially for infrastructure / internal computations, any matters regarding clustering are out of scope of this proposal. It focuses on guarantees achievable after a single compilation cycle.

Here is an issue where clustering problems was brought up: gleam-lang/otp#9

[hissssst]

type Sound ! Counter {
  receive {
    Quack -> state.count + 1
    Woof -> state.count - 10
  }
}

Where does this state variable come from? I mean I get this, but this is generally a bad idea to have variables appearing out of nowhere

[cognivore]

Oh sure, it should be receive state.

[lpil]

Some really interesting stuff here! Thank you.

If !, *, and ^ were English words what would they be?

What does basis mean?

Is it possible to design a supervision tree with this system? So that groups of processes can be considered a single unit and be restarted collectively if one fails?

Why is it that there are only async messages? Does this imply no selective receives and no blocking receive?

[cognivore]

Regarding basis:

My understanding is that side effects are ambient (implicit) in Gleam.
From what I understand (and hope) about the default values proposal, default values shall be static.
I argue that for the purpose of ergonomic definition of "state zero" for our "free" actors, it would be beneficial to have an effectful initialisation. I decided to introduce a special syntax for function new/0, basically. It's not instrumental to the proposal, but it's there to make sure that in case of

fn onomatopoeia(animal: Animal, send: Sound ! Counter) -> Ok {
  case animal {
    Wolf -> send Woof,
    Duck -> send Quack
  }
}

the author of the code won't need to worry about instantiating Counter. That said, perhaps we can and should move basis into the messaging types?..

[cognivore]

Is it possible to design a supervision tree with this system? So that groups of processes can be considered a single unit and be restarted collectively if one fails?

I would say that for the initial implementation I would target "OFO" only, grouping those by the module where messaging types are defined. I see no problem, however, to implement dependencies between different messaging types within the same module.

Generally speaking, if some sort of linking semantics is implemented between free actors, I would expect it to be expressable at type level only, and I currently don't see a way to do it elegantly.

[cognivore]

Why is it that there are only async messages? Does this imply no selective receives and no blocking receive?

Intuitively, it would be significantly easier to implement this proposal starting with only supporting casts. I'm not sure what's the problem with "selective" receives though. In an implementation for X ! Y we can flip a coin and only accept a certain message if it comes out heads, for instance.

[lpil]

Thank you.

Another thing I'm wondering is could this be implemented using an external code generation tool with some declarative configuration. This certainly is not as elegant but some aspects of this remind me of problems where code generation is common such as protobuf and graphql. It could even be used from Erlang in this case.

[cognivore]

Perhaps.

Intuitively, for it to be a nice experience for authors, we should have "gleam as a library" available to them.