On the subject of Subjects

[karlsson]

Howdy gleamlins,

I am a "retired" Erlanger. Having some more time, and after listening to Hayleigh Thompson's interesting talk at Code Beam Lite STHLM, I thought I check out the new gleam on the beam. Now it turned out to have been around for some, at least 6?, years so I might have missed something there.

My first impression is that I am .. impressed. The static typing and tooling seems to go hand in hand.

The first mental obstacle (for me) was message passing and Subjects and Selectors. Passing Subjects back and forth between processes was a bit unusual for some used to named processes and receive clauses using pattern matching. I wasn't able to find some good examples, maybe I did not check enough, but after playing around a bit I feel it is quite nice.

If I understand right, Subject classes (types) are a set of Message types and the subject instance is the tuple of the Pid and this set of messages?
This maps quite nice to the Signals (Messages) and Signallists (Subjects) in SDL (Specification and Description Language) which is the pre-UML notation used when building communication systems in the previous millennium.

Below is a non-formal and very simplified SDL block description example for a card entry system. Instead of a signallist I added a gleam type.

And a Message Sequence Diagram for the successful case could look like:

So now one can specify the gleam types:

// --------- Authentication ---------
// Messages
pub type AuthRequest {
  AuthRequest(requester: AuthResponseSubject, id: String, pincode: Digits)
}

pub type AuthResponse {
  AuthOk
  AuthError(AuthErrorCause)
}

pub type AuthErrorCause {
  WrongPin
  UserDoesNotExist
}

// Subjects
pub type AuthRequestSubject =
  Subject(AuthRequest)

pub type AuthResponseSubject =
  Subject(AuthResponse)

// --------------- CardReaderService/Client -----------------
// Messages

type CardInserted {
  Inserted(card_client: CardResponseSubject, index: Int, id: String)
}

type KeysEntered {
  Keys(digits: Digits)
}

type Digits =
  List(Int)

type CardResponse {
  EjectCard
  DisplayError
  OpenDoor
  EnterKeys(keyreader_subject: KeysEnteredSubject)
}

// Subjects
type CardInsertedSubject =
  Subject(CardInserted)

type KeysEnteredSubject =
  Subject(KeysEntered)

type CardResponseSubject =
  Subject(CardResponse)

// --------- Manager -------------------
type Manager {
  CardInsertedService(card_reader: CardInsertedSubject)
  AuthService(auth_checker: AuthRequestSubject)
}

The Manager type keeps track of the services (singleton) processes.

Ulf Wiger had a presentation at the EUC 2005 where he showed how selective receive solves the "complexity explosion problem", avoiding to have to handle all possible messages in every state. Subjects and Selectors address this problem. Now, selective receive might come back and bite you, overflowing the message queue, if you do not handle (eventually) high rate messages and/or messages with no flow control.
I think Subjects are a bit of a nice in-between solution since you need to handle all the messages that may appear on one interface, or several if combined with a Selector.
This may be common sense for the experienced gleam programmer. I hope I have understood the concepts right here?
To conclude, gleam is not a object-oriented language but rather a subject-oriented one. 😄

I attach the full gleam file (as .txt) for the interested.