Algebraic Thinking for Evolution of Pure Functional Domain Models

Algebraic Thinking for
Evolution of Pure
Functional Domain Models
Debasish Ghosh
@debasishg

Traveling back in time ..
more than 40 years ..
Copyright: https://www.npr.org/2014/06/17/318605598/turn-the-clock-back-or-forward-with-time-traveling-tales

c !:= 0
for i !:= 1 step 1 until n do
c !:= c + a[i] x b[i]
Von Neumann program for Inner Product
“It is dynamic and repetitive.
One must mentally execute it to understand it”
- John Backus

Def Innerproduct =
(Insert +) o (ApplyToAll X) o Transpose
Composition (o), Insert, ApplyToAll etc. are
functional forms that combine existing functions to
form new ones
Functional program for Inner Product
“It’s structure is helpful in understanding it
without mentally executing it”
- John Backus

- John Backus
“.. programs can be expressed in a language that has
an associated algebra. This algebra can be used to
transform programs and to solve some equations
whose " unknowns" are programs, in much the same
way one solves equations in high school algebra.
Algebraic transformations and proofs use the
language of the programs themselves, rather than the
language of logic, which talks about programs.”

What is an Algebra ?
Algebra is the study of algebraic structures
In mathematics, and more specifically in abstract
algebra, an algebraic structure is
a set (called carrier set or underlying set)
with one or more finitary operations defined on it
that satisfies a list of axioms
-Wikipedia
(https://en.wikipedia.org/wiki/Algebraic_structure)

SetA
ϕ : A × A → A
for (a, b) ∈ A
ϕ(a, b)
a ϕ b
given
a binary operation
for specific a, b
or
The Algebra of Sets

Algebraic Thinking
• Denotational Semantics
✦ programs and the objects they manipulate are symbolic
realizations of abstract mathematical objects
✦ the purpose of a mathematical semantics is to give a
correct and meaningful correspondence between programs
and mathematical entities in a way that is entirely
independent of an implementation [Scott & Strachey,
1971]

Algebraic Thinking
Denotational Semantics

Operational Thinking
• Operational Semantics
✦ formalize program implementation and how the various
functions must be computed or represented
✦ not much of a relevance towards algebraic reasoning

Option.apply[A](a: A): Option[A]
Option.empty[A]: Option[A]
Option[A]
A: Carrier Type of the algebra
Introduction Forms

def f[A, B](func: A !=> B) = ???
optionA.map(f)
!// Option[B]
def f[A, B](func: A !=> Option[B]) = ???
optionA.!flatMap(f)
!// Option[B]
Option[A]
Introduction Forms
Combinators

def f[A, B](func: A !=> B) = ???
optionA.map(f)
!// Option[B]
optionA.!flatMap(f)
!// Option[B]
optionA.getOrElse(default)
!// A or B !>: A
Option[A]
Introduction Forms
Combinators
Eliminator Forms

def f[A, B](func: A !=> B) = ???
optionA.map(f)
!// Option[B]
optionA.!flatMap(f)
!// Option[B]
optionA.getOrElse(default)
!// A or B !>: A
Option.empty[Int].!flatMap(!!...) !== Option.empty[Int]
!// res1: Boolean = true
Option.empty[Int].map(!!...) !== Option.empty[Int]
!// res2: Boolean = true
Option[A]
Introduction Forms
Combinators
Eliminator Forms
Laws

Introduction Forms
Combinators
Eliminator Forms
Laws
algebra

• Thinking in terms of combinators (map/
!flatMap/fold) and their laws is algebraic
thinking
• Thinking in terms of concrete implementations
(pattern match with Some/None) is
operational thinking

Module with an algebra
trait Monoid[A] {
def zero: A
def combine(l: A, r: !=> A): A
}
!//identity
combine(x, zero) =
combine(zero, x) = x
!// associativity
combine(x, combine(y, z)) =
combine(combine(x, y), z)

Module with an Algebra
trait Foldable[F[_]] {
def foldl[A, B](as: F[A], z: B, f: (B, A) !=> B): B
def foldMap[A, B](as: F[A], f: A !=> B)
(implicit m: Monoid[B]): B =
foldl(as,
m.zero,
(b: B, a: A) !=> m.combine(b, f(a))
)
}

def mapReduce[F[_], A, B](as: F[A], f: A !=> B)
(implicit ff: Foldable[F], m: Monoid[B]) =
ff.foldMap(as, f)
https://stackoverflow.com/a/4765918

ff.foldMap(as, f)
a complete map/reduce program abstracted as a
functional form

ff.foldMap(as, f)
a complete map/reduce program abstracted as a
functional form
derived intuitively from the algebras of a fold and a
monoid

Building and understanding higher order abstractions is
much more intuitive using algebraic than operational
thinking

Building and understanding higher order abstractions is
much more intuitive using algebraic than operational
thinking
algebraic thinking scales

Healthy recipes for an
algebra
(in a statically typed functional programming language)

Polymorphic
trait Monoid[A] {
def zero: A
def combine(l: A, r: !=> A): A
}

Lawful
!//identity
combine(x, zero) =
combine(zero, x) = x
!// associativity
combine(x, combine(y, z)) =
combine(combine(x, y), z)

Compositional
trait Foldable[F[_]] {
def foldl[A, B](as: F[A], z: B,
f: (B, A) !=> B): B
def foldMap[A, B](as: F[A], f: A !=> B)
(implicit m: Monoid[B]): B =
foldl(as, m.zero,
(b: B, a: A) !=> m.combine(b, f(a)))
}

Restricted
def mapReduce[F[_], A, B](as: F[A],
f: A !=> B)
(implicit ff: Foldable[F],
m: Monoid[B]) =
ff.foldMap(as, f)

f:A!=>B and g:B!=>C, we should
be able to reason that we can
compose f and g algebraically
to build a larger function h:A!=>C
Implementation
Independent

Open
trait Repository[M[_]] {
def query[A](key: String): M[Option[A]]
!//!..
}

What is a domain model ?
A domain model in problem solving and software engineering is a
conceptual model of all the topics related to a specific problem. It
describes the various entities, their attributes, roles, and
relationships, plus the constraints that govern the problem domain.
It does not describe the solutions to the problem.
Wikipedia (http://en.wikipedia.org/wiki/Domain_model)

https://msdn.microsoft.com/en-us/library/jj591560.aspx

A Bounded Context
• has a consistent vocabulary
• a set of domain behaviors modeled as
functions on domain objects
implemented as types
• each of the behaviors honor a set of
business rules
• related behaviors grouped as modules

Domain Model = ∪(i) Bounded Context(i)
Bounded Context = { m[T1,T2,..] | T(i) ∈ Types }
Module = { f(x,y,..) | p(x,y) ∈ Domain Rules }
• domain function
• on an object of types x, y, ..
• composes with other functions
• closed under composition
• business rules

Domain Model = ∪(i) Bounded Context(i)
Bounded Context = { m[T1,T2,..] | T(i) ∈ Types }
Module = { f(x,y,..) | p(x,y) ∈ Domain Rules }
• domain function
• on an object of types x, y, ..
• composes with other functions
• closed under composition
• business rules
Domain Algebra
Domain Algebra

Client places order
- flexible format
1

Client places order
- flexible format
Transform to internal domain
model entity and place for execution
1 2

Client places order
- flexible format
Transform to internal domain
model entity and place for execution
Trade & Allocate to
client accounts
1 2
3

def orders(csvOrder: String): M[List[Order]]
def execute(orders: List[Order],
market: Market,
brokerAccountNo: AccountNo)
: M[List[Execution]]
def allocate(executions: List[Execution],
clientAccounts: List[AccountNo])
: M[List[Trade]]
trait Trading[M[_]] {
}
Effect Type that parameterizes
the Trading algebra

def orders(csvOrder: String): M[NonEmptyList[Order]]
def execute(orders: NonEmptyList[Order],
market: Market,
: M[NonEmptyList[Execution]]
def allocate(executions: NonEmptyList[Execution],
clientAccounts: NonEmptyList[AccountNo])
: M[NonEmptyList[Trade]]
}
the Trading algebra

Effects
• an algebraic way of handling computational
effects like non-determinism, probabilistic non-
determinism, exceptions, interactive input-
output, side-effects, continuations etc.
• first formalized by Plotkin and Power [2003]

Option[A]
Either[A,B]
(partiality)
(disjunction)
List[A]
(non-determinism)
Reader[E,A]
(read from environment aka dependency Injection)
Writer[W,A]
(logging)
State[S,A]
(state management)
IO[A]
(external side-effects)
.. and there are many many more ..

F[A]
The answer that the
effect computes
The additional stuff
modeling the computation

• Error handling ?
• throw / catch exceptions is not RT
• Partiality ?
• partial functions can report runtime exceptions if
invoked with unhandled arguments (violates RT)
• Reading configuration information from environment ?
• may result in code repetition if not properly handled
• Logging ?
Side-effects

Side-effects
• Database writes
• Writing to a message queue
• Reading from stdin / files
• Interacting with any external resource
• Changing state in place

modularity
side-effects don’t compose

def orders(csvOrder: String): M[NonEmptyList[Order]]
def execute(orders: NonEmptyList[Order],
market: Market,
: M[NonEmptyList[Execution]]
def allocate(executions: NonEmptyList[Execution],
clientAccounts: NonEmptyList[AccountNo])
: M[NonEmptyList[Trade]]
}
Effect Types offer compositionality even in the
presence of side-effects
All M[_]’s indicate that some
computation is going on here

• The M[_] that we saw is an opaque type - it
has no denotation till we give it one
• The denotation that we give to M[_] depends
on the semantics of compositionality that we
would like to have for our domain model
behaviors

The Program
def generateTrade[M[_]: Monad](T: Trading[M]) = for {
orders !<- T.orders(csvOrders)
executions !<- T.execute(orders, Market.NewYork, brokerAccountNo)
trades !<- T.allocate(executions, clientAccountNos)
} yield trades

The Program
def generateTrade[M[_]: Monad](T: Trading[M]) = for {
} yield trades
Composition of the algebra of a Monad with our domain algebra of trading

Parametricity
• Trading module is polymorphic on M[_].We could
have committed to Trading[IO] upfront - but then
we are making decisions on behalf of the call site.This is
premature evaluation
• In implementation we can say M[_]: Monad and
suddenly the only operations available to us are pure
and !flatMap.This reduces the surface area of
implementation.With IO we could have done anything
in the implementation.

def postBalance(trades: NonEmptyList[Trade]
: F[NonEmptyList[Balance]]
trait Accounting[M[_]] {
}
the Accounting algebra

The Program
def generateTradeAndPostBalance[M[_]:Monad]
(T:Trading[M], A:Accounting[M]) = for {
balances !<- A.postBalance(trades)
} yield (trades, balances)

The Program
def generateTradeAndPostBalance[M[_]:Monad]
(T:Trading[M], A:Accounting[M]) = for {
balances !<- A.postBalance(trades)
} yield (trades, balances)
Composition of multiple domain algebras

• .. we have intentionally kept the algebra open
for interpretation ..
• .. there are use cases where you would like to
have multiple interpreters for the same
algebra ..

Interpreters
class TradingInterpreter[M[+_]]
(implicit E: MonadError[M, Throwable],
R: ApplicativeAsk[M, Repository[M]])
extends Trading[M] {
!//!..
}
monad with error handling
asks for a repository
from the environment

Interpreters
class TradingInterpreter[M[+_]]
(implicit E: MonadError[M, Throwable],
R: ApplicativeAsk[M, Repository[M]])
extends Trading[M] {
!//!..
}
monad with error handling
asks for a repository
from the environment
InMemoryRepository[M]
DoobieRepository[M]

Finally ..
implicit val !.. = !//!..
generateTradeAndPostBalances(
new TradingInterpreter[IO],
new AccountingInterpreter[IO]
)

- Rob Norris at scale.bythebay.io talk - 2017 (https://www.youtube.com/
watch?v=po3wmq4S15A)
“Effects and side-effects are not the same thing. Effects are
good, side-effects are bugs.Their lexical similarity is really
unfortunate because people often conflate the two ideas”

Takeaways
• Algebra scales from that of one single data type to
an entire bounded context
• Algebras compose enabling composition of
domain behaviors
• Algebras let you focus on the compositionality
without any context of implementation
• Statically typed functional programming is
programming with algebras

Takeaways
• Abstract early, interpret as late as possible
• Abstractions / functions compose only when they are
abstract and parametric
• Modularity in the presence of side-effects is a challenge
• Effects as algebras are pure values that can compose based
on laws
• Honor the law of using the least powerful abstraction
that works

References
• Scott, D., and Strachey, C. [1971 ]. Towards a mathematical semantics for computer languages.
Proc. Symp. on Computers and Automata, Polytechnic Institute of Brooklyn; also Tech. Mon. PRG-6, Oxford U. Computing Lab., pp.
19-46.
• Gordon Plotkin, and John Power. “Algebraic Operations and Generic Effects.” Applied Categorical Structures 11 (1): 69–94. 2003.
doi:10.1023/A:1023064908962.

Algebraic Thinking for Evolution of Pure Functional Domain Models

More Related Content

What's hot (20)

Similar to Algebraic Thinking for Evolution of Pure Functional Domain Models (20)

More from Debasish Ghosh (10)

Recently uploaded (20)

Algebraic Thinking for Evolution of Pure Functional Domain Models