The most imaportant ideas in modern functional programming are:

• It's all about data

  functional programming is all about putting data first. The first is defining what kinds of data we have in a problem domain, and what kinds of transformations we want on them. Then we building up the data structures and the code to do the transformations.

• Managing of side-effect

  functional programming is not about pure functions any more. Eventually, programs will produce side-effects and side-effect management is a puzzle with many parts.

Definition:

Code:

// Tuple2[A, B] - scala implementation of product type
def fst[A,B]: ((A,B)) => A = prod => prod._1  // _1 - scala impl of fst
def snd[A,B]: ((A,B)) => B = prod => prod._2  // _2 - scala impl of snd

def delta[A, B, C]: (C => A) => (C => B) => (C => (A,B)) =
  f => g => x => (f(x), g(x))


val f: String => Int    = str => str.length
val g: String => String = str => str.toUpperCase
val h = delta(f)(g)

forAll { (any: String) =>
  (h andThen fst)(any) == f(any) &&
  (h andThen snd)(any) == g(any)
}
          

View (combine function):

Code:

val f: String => Int    = str => str.length
val g: String => String = str => str.toUpperCase

val h = f *** g

h("Hello", "Workday") shouldEqual (5, "WORKDAY")
          

Definition:

Code:

// Either[A, B] - scala implementation of co-product type
def left[A,B]: A => Either[A,B]  = a => Left(a)
def right[A,B]: B => Either[A,B] = b => Right(b)

def delta[A, B, C]: (A => C) => (B => C) => (Either[A, B] => C) =
  f => g => x => x match {
    case Left(a)  => f(a)
    case Right(b) => g(b)
  }

val f: Int    => String = i   => i.toString
val g: String => String = str => str * 2
val h = delta(f)(g)

forAll { (anyStr: String, anyInt: Int) =>
  (left andThen h)(anyInt) == f(anyInt) &&
  (right andThen h)(anyStr) == g(anyStr)
}
          

View (merge function):

Code:

val f: String => Int    = str => str.length
val g: String => String = str => str.toUpperCase

val h = f ||| g

h apply Left[String, String]("Hello")  shouldEqual 5
h apply Right[String, String]("Hello") shouldEqual "HELLO"
          

KleisliCategory Type-Class:

type Kleisli[M[+_], -A, +B] = A => M[A]

trait KleisliCategory[M[+_]]
  extends Category[({type λ[-α, +β] = Kleisli[M, α, β]})#λ] {
  // ...
}
          

KleisliCategory Type-Class (with Kind Projector plugin):

trait KleisliCategory[M[+_]]
  extends Category[Kleisli[M, -?, +?]] {
  // ...
}
          

KleisliArrow Type-Class:

type Kleisli[M[+_], -A, +B] = A => M[A]

trait KleisliCategory[M[+_]]
  extends Category[Kleisli[M, -?, +?]] {
// ...
}

trait KleisliArrow[M[+_]]
  extends Arrow[Kleisli[M, -?, +?]]
  with KleisliCategory[M] {

// ...
}
          

• All functions have effects, the things the function does. The simplest effect is just accepting parameters and returning a single value as a result.
• Everything else we might conceive a function doing is a side-effect. By wrapping a value in a container, we can emulate all the various side-effects that are possible.

A => List[B]
                  

A => Option[B]
                  

A => Future[B]
                  

A => (S, B)
                  

A => (Unit => E, B)
                  

Common data manipulation techniques for dealing with side-effecting containers:

Functor & Monad (essence):

Functor  :  A   =>   B                      =>   C[A]  =>  C[B]
Monad    :  A   => C[B]                     =>   C[A]  =>  C[B]
          

Arrow (essence):

Arrow   :  (A  =>   B ) >>> (B  =>   D )    =>   A  =>   D
Kleisli :  (A  => C[B]) >=> (B  => C[D])    =>   A  => C[D]
          

• Arrows build a container for the whole functions, where Monads just give a common structure for their outputs.
• Arrows can have more then one input.

For:

case class User(id: Int, name: String, password: String)

def getUserById: Int => Option[User] = ...
def updateDbUser: User => Option[Int] = ...

def updateName: String => User => Option[User] = ...
def updatePassword: String => User => Option[User] = ...
          

Monad usege:

def update(id: Int, update: User => Option[User]) =
  getUserById(id).flatMap(update).flatMap(updateDbUser)

update(10, (user: User) => updateName(name).flatMap(updatePassword(password)))
          

Kleisli usege:

def update(id: Int, update: User => Option[User]) =
  Kleisli { getUserById(id) } >==> update >==> updateDbUser

update(10, Kleisli { updateName(name) } >==> updatePassword(password))
          

KleisliArrow Type-Class (based on Monad):

case class Kleisli[M[+ _], -A, +B](run: A => M[B])

trait KleisliCategory[M[+_]] extends Category[(Kleisli[M, -?, +?]] {
  implicit def Monad: Monad[M]

  def id[A]: Kleisli[M, A, A] = Kleisli(a => Monad.point(a))

  def compose[A, B, C](bc: Kleisli[M, B, C], ab: Kleisli[M, A, B]): Kleisli[M, A, C] =
    bc.flatMap(run(ac), k.run(_: B)))
}

trait KleisliArrow[M[+_]] extends Arrow[Kleisli[M, -?, +?]] with KleisliCategory[M] {

  def arr[A, B](f: A => B): Kleisli[M, A, B] = Kleisli(a => Monad.point(f(a)))

  def first[A, B, C](f: Kleisli[M, A, B]): Kleisli[M, (A, C), (B, C)] =
    Kleisli[M, (A, C), (B, C)] { case (a, c) => Monad.map(f.run(a), (b: B) => (b, c)) }
}
          

And back to the Arrow

Motivation, is to find a generic interface for arrow wich cannot be based on monad.

trait ArrowApply[~>[-_, +_]] extends Arrow[~>] {
  def app[A, B]: (A ~> B, A) ~> B
}

case class ArrowMonad[~>[-_, +_], +A](run: Unit ~> A)

implicit def _asMonad[~>[-_, +_]](implicit i: ArrowApply[~>]):
  Monad[ArrowMonad[~>, +?]] = new Monad[ArrowMonad[~>, +?]] {

    type M[+A] = ArrowMonad[~>, A]

    def point[A](x: => A): M[A] = ArrowMonad { i.arr(_ => x) }
    def flatMap[A, B](m: M[A], f: A => M[B]): M[B] =
      ArrowMonad[~>, B] { m.run >>> i.arr((x: A) => (f(x).run, ())) >>> i.app[Unit, B] }
  }

trait KleisliArrowApply[M[+ _]] extends ArrowApply[Kleisli[M, -?, +?]] {
  private type ~>[-A, +B] = Kleisli[M, A, B]
  def app[A, B]: (A ~> B, A) ~> B = Kleisli { case (f, a) => (f.run)(a) }
}
          

Railway tracks:

Arrow as Framework for:

• Error handling
• Single Track Function
• Dead-end Function
• Supervisory Function (handle "both track")

Dataflow programming (programming paradigm)

Initial:

case class User(id: Int, name: String, psswd: String, email: String)
def getUserById: Int => Either[Err, User] = ???
def updateDbUser: User => Either[Err, Int] = ???
def updateName: String => User => User = ???
def sendEmail: User => Unit = ???

def id[T]: T => T = x => x
def leftId[E, T]: Err => Either[E, T] = x => Left { x }
def fst[A, B]: (A, B) => A = _._1
          

val run =
  getUserById >>>
  updateName(name).right >>>
  ((id[User] &&& sendEmail) >>> fst).right >>>
  (leftId[Err, Int] ||| updateDbUser) // Either[Err, Int]
          

val run = Kleisli[Either[Err, +?], Int, User] {
    getUserById >>>
    updateName(name).right >>>
    ((id[User] &&& sendEmail) >>> fst).right
  } >==> updateDbUser // Either[Err, Int]