Scala Snippets #2: Dependent Types in Scala - A practical example by Manish Katoch


Ready for part 2 of the Scala Snippets with Lead Consultant, Manish Katoch?

You'll find out more about type-level programming in Scala!

Missed part 1, check it out here


'Of late, I have been fascinated with type-level programming in Scala. The more I play with it, the more I get excited about it. Although most of my production implementations have been at the framework level, there is no reason why it cannot be utilized to drive business logic.

Let’s try to build our understanding of this paradigm using a trivial but a practical use case.

Acme online store has a flourishing business. They have a membership status associated with each of their customers in the form of AcmeCards. It’s a usual loyalty program with three tiers: Platinum, Gold and Silver. It is also a festive season and Acme has decided to give flat discounts for each tier. One of the backend API (they have a UI and BFF setup) of the Acme store needs to display the membership details and the applied discount.

The following story sums up the expected behaviour:

Given the online store has members with platinum, gold, silver AcmeCards and the store has discount schemes associated with memberships

When a member puts item in cart and checks out his/her cart

Then display member’s membership, the discount applied and the points required for next upgraded membership.

Now, a classical way of implementing this would be to have a repository to get the member and its type from the database given an identifier. We can further derive AcmeCard subscription for the identified member. But if we pause and rethink, we realise that we are writing all of the logic to make necessary selections. All the validations are done, decisions are made, flows are selected, at the run time. This leaves our interface prone to runtime errors. Wouldn’t it be great if the compiler could help us predict such errors at compile time itself?

Scala can. If we code for types not for data.

Type Level programming is a paradigm, when provided with a well constrained strongly type system, allows dynamic flows generation at compile time.

A strong type system is one where the types are strictly constrained and the relationships established. The constraints guide the compiler to make decisions at certain compile points as well as predict if the compiled code succeed when run. If we constrain our system correctly, we can defer all the relevant object creation on compiler!

How do we go about it? To begin with, since all our computations are going to be based on types, each of our concerns should be represented by types.'Member' type represents a customer of Acme. For the sake of simplicity, we will only consider system identifier, names and the points accrued.

case class Member(id: String, name: String, points: Long = 0)

'MemberType' determines whether the member is a first time customer, or a frequent shopper or a patron of Acme Store.

trait MemberType {val member: Member}

case class FirstTimer(member: Member) extends MemberType
case class FrequentShopper(member: Member) extends MemberType
case class Patron(member: Member) extends MemberType

'AcmeCard' represents the membership levels.

abstract class AcmeCard(member: Member, levelName: String)

case class Silver(member: Member) extends AcmeCard(member,"silver") 
case class Gold(member: Member) extends AcmeCard(member,"gold")

case class Platinum(member: Member) extends 

'Discounted' type represents what kind of discounts are associated with each AcmeCard. Now to make a decision, the compiler needs to know how to choose and create a type. This means that concern types like 'Discounted' must be implicitly instantiable as shown below.

trait Discounted[T] { def getDiscount: Double }

object Discounted { 
// apply method called by compiler to instantiate if no instance 
found  def apply[T](implicit discounted: Discounted[T]) = discounted

def createDiscounted[T](fn: () => Double) = new Discounted[T] {  
override def getDiscount: Double = fn()

//implicit instances of Discounted for each Membership Card
implicit val silverCardDiscounted: Discounted[Silver] = 
createDiscounted( () => 5.0)

implicit val goldCardDiscounted: Discounted[Gold] = 
createDiscounted(() => 10.0)

implicit val platinumCardDiscounted: Discounted[Platinum] = 
createDiscounted(() => 15.0) }

'AcmeCardPrinter' provides a trait that emits trademark marketing names for the AcmeCards.

trait AcmeCardPrinter[T] { def print(t: T): String }

object AcmeCardPrinter {

def apply[T](implicit prettyPrinter: AcmeCardPrinter[T]): 
AcmeCardPrinter[T] = prettyPrinter

implicit val silverAcmeCardPrinter: AcmeCardPrinter[Silver] = new 
AcmeCardPrinter[Silver] { 
override def print(t: Silver): String = "AcmeCard® Silver Start™"

implicit val goldAcmeCardPrinter: AcmeCardPrinter[Gold] = new
AcmeCardPrinter[Gold] {
override def print(t: Gold): String = "AcmeCard® Gold Delight™"

implicit val platinumAcmeCardPrinter: AcmeCardPrinter[Platinum] = 
new AcmeCardPrinter[Platinum] {
override def print(t: Platinum): String = "AcmeCard® Platinum 

'UpgradeRequirementCheck' trait provides the points required for the next AcmeCard upgrade. It has some additional logic to determine the points required by the customer.

trait UpgradeRequirementCheck[T] {
def pointsToUpgrade(currentPoint: Long): Long

object UpgradeRequirementCheck {

def apply[T](implicit upgradeEligibility: 
UpgradeRequirementCheck[T]) = upgradeEligibility

def createUpgradeEligibility[T](fn:() => Long) = new 
UpgradeRequirementCheck[T] {
override def pointsToUpgrade(currentPoint: Long): Long = {
val targetPoints = fn()
if (targetPoints > 0 && targetPoints > currentPoint)
    targetPoints - currentPoint
else 0

implicit val firstTimerUpgrade: UpgradeRequirementCheck[Silver] = 
createUpgradeEligibility( () => 10000L)

implicit val frequentShopperUpgrade: UpgradeRequirementCheck[Gold] = 
createUpgradeEligibility(() => 100000L)

implicit val patronDUpgrade: UpgradeRequirementCheck[Platinum] = 
createUpgradeEligibility(() => 0L) }

Now let’s revisit our story. Given a member, we need to display his/her AcmeCard information, the points required for the next upgrade and the discount applicable for further purchases. We have 'Member' type to work with but our traits 'UpgradeRequirementCheck','AcmeCardPrinter' and 'Discounted' work with AcmeCard type. We need to find a way to map 'Member' to 'AcmeCard'. Given a 'Member', we need to find the appropriate 'AcmeCard' and then have Scala figure out relevant instances for traits 'UpgradeRequirementCheck','AcmeCardPrinter' and 'Discounted'.

For type mapping, let’s introduce 'Privilege' trait which provides a way to capture the mapped type in a publicly exposed type variable.

trait Privilege[T] {
type OutType
def getMember(t: T): OutType
object Privilege { 
type Aux[T, R] = Privilege[T] { type OutType = R }

def apply[T](implicit privilege: Privilege[T]): Aux[T,
privilege.OutType] = privilege

implicit def materializeSilverCard[R]: Aux[FirstTimer,Silver] = new 
Privilege[FirstTimer] { 
type OutType = Silver
override def getMember(t: FirstTimer): OutType = Silver(t.member)

implicit def materializeGoldCard[R]: Aux[FrequentShopper,Gold] = new
Privilege[FrequentShopper] {
type OutType = Gold
override def getMember(t: FrequentShopper): OutType = Gold(t.member) 

implicit def materializePlatinumCard[R]: Aux[Patron,Platinum] = new 
Privilege[Patron] { 
type OutType = Platinum
override def getMember(t: Patron): OutType = Platinum(t.member)

The design pattern is also known as Aux Pattern and is an important tool in your tool-set. You will invariably use Aux pattern when working with type-level programming.

With 'Privilege' defined, we can see below how the type conversion would happen on runtime and also how we get the corresponding 'AcmeCard' for a given member type.

val johnDoe = FirstTimer(Member("123456","John Doe"))
val janeDoe = FrequentShopper(Member("567890","Jane Doe", 50500))

//A sample function to get a mapper to give a AcmeCard of type R for 
a member of type T

def getPrivilegeType[T,R](member: T)(implicit privilege: 
Privilege.Aux[T,R]) = privilege

/*res0: Privilege.Aux[FrequentShopper,Gold] =

/*res0: Privilege.Aux[FirstTimer,Silver] = 

All we need to do now is to forward this type to the respective downstream handlers and Scala compiler can take care of the rest! Let’s take a look at the final piece:

def getMembershipInformation[T <: MemberType,R](memberType: T)
    privileged: Privilege.Aux[T,R],
    printer: AcmeCardPrinter[R],
    upgradeEligibility: UpgradeRequirementCheck[R],
    discounted: Discounted[R] ): String = {
val pointsToUpgrade = 
val discount = discounted.getDiscount
val cardName = printer.print(privileged.getMember(memberType))
val memberName =

s"Dear $memberName\n" + s"You are proud owner of $cardName\n" + s"We 
have applied special discount of $discount%\n" + s"Psst! you need
$pointsToUpgrade points for next upgrade!"

What’s going on here? When Scala sees a call for 'getMembershipInformation' for a given 'Member', it tries to bring (import or create) a 'Privilege.Aux' type into scope. As we have seen above, The Aux will provide the 'AcmeCard' type in 'R'. This “captured” type can be further used in the same call scope to import or instantiate other required implicit instances.

Let’s see this in action:

import AcmeCardPrinter._
import Privilege._
import Discounted._
import UpgradeRequirementCheck._

/*res0: String =
Dear John Doe
You are proud owner of AcmeCard® Silver Start™
We have applied special discount of 5.0%
Psst! you need 10000 points for next upgrade!*/

/*res0: String =
Dear Jane Doe
You are proud owner of AcmeCard® Gold Delight™
We have applied special discount of 10.0%
Psst! you need 49500 points for next upgrade!*/

And that marks our story done (Dev Done at least)!.

We created highly disconnected components, defined our business domain using constrained implicit methods. Any change in such setup, will provide feedback at compile time and ensure that application sanity (domain-wise) is not compromised. Type-level programming is a very effective tool which, I firmly believe, has a place in writing domain rich applications, not just frameworks. Give it a shot!'


This article was written by Manish Katoch and originally posted on