Juan José Vázquez juanjovazquez

A state machine is defined as follows:

Input - a set of inputs
Output - a set of outputs
State - a set of states
S0 ∈ S - an initial state
T : Input * State -> Output * State - a transition function

If you model your services (aggregates, projections, process managers, sagas, whatever) as state machines, one issue to address is management of State. There must be a mechanism to provide State to the state machine, and to persist resulting State for subsequent retrieval. One way to address this is by storing State is a key-value store. Another way is to use a SQL database. Yet another way is event sourcing. The benefit of even sourcing is that you never need to store State itself. Instead, you rely on the Output of a service to reconstitute state. In order to do that, the state machine transition function needs to be factored into two functions as follows:

Recursion and Trampolines in Scala

Recursion is beautiful. As an example, let's consider this perfectly acceptable example of defining the functions even and odd in Scala, whose semantics you can guess:

def even(i: Int): Boolean = i match {
  case 0 => true
  case _ => odd(i - 1)
}

def odd(i: Int): Boolean = i match {

Applied Functional Programming with Scala - Notes

1. Mastering Functions

A function is a mapping from one set, called a domain, to another set, called the codomain. A function associates every element in the domain with exactly one element in the codomain. In Scala, both domain and codomain are types.

val square : Int => Int = x => x * x

Revisiting Tagless Final Interpreters

Tageless Final interpreters are an alternative to the traditional Algebraic Data Type (and generalized ADT) based implementation of the interpreter pattern. This document presents the Tageless Final approach with Scala, and shows how Dotty with it's recently added implicits functions makes the approach even more appealing. All examples are direct translations of their Haskell version presented in the Typed Tagless Final Interpreters: Lecture Notes (section 2).

The interpreter pattern has recently received a lot of attention in the Scala community. A lot of efforts have been invested in trying to address the biggest shortcomings of ADT/GADT based solutions: extensibility. One can first look at cats' Inject typeclass for an implementation of [Data Type à la Carte](http://www.cs.ru.nl/~W.Swierstra/Publications/DataTypesA

	{-# LANGUAGE TypeFamilies #-}

	import Data.Function (on)
	import Control.Applicative

	data EventData e = EventData {
	eventId :: Int,
	body :: Event e
	}

	-- Our goal is to create a type describing a list of events. This is our
	-- type-level DSL.
	-- We will then use typeclass resolution to "interpret" this type-level DSL
	-- into two things:
	-- 1. A comma-separated list of events
	-- 2. A method that, when given an event name and a payload, will try to parse
	-- that event type with the payload. A form of dynamic dispatching
	--
	-- To model a list of types we will use tuples. You can imagine the list of
	-- types "Int, String, Char" to look like:

	admin:
	port: 9990
	ip: 0.0.0.0

	routers:
	# http 1.1: service -> [linkerd] -> linkerd -> service
	# should lookup consul service then rewrite outgoing port to linkerd
	- label: http1-out
	protocol: http
	servers: