straszydlo

Freedom fuel

Wed, 20 Aug 2025 00:00:00 +0000

In a nutshell

I just finished watching a wonderful episode of Kurzgesagt¹ about alcohol and our relationship with it. Despite starting with calling alcohol “the most harmful substance on Earth”, the video could serve as an ad for ethanol consumption — it explains in great detail why it makes us feel great, and it even suggests that alcohol helped societies thrive by helping overcome anxiety and break down social barriers.

While that claim might not be true, this “pact with the devil”, as Kurzgesagt calls it, might actually have had a much more technical benefit for early societies. Ethanol is quite effective as a crude food preservative — and what’s even better, alcohol fermentation pretty much happens on its own. It was an invaluable tool for our earliest ancestors, who oftentimes had to endure long periods without access to fresh fruits or grains. I’m far from advocating for ingesting alcohol, as nowadays we have healthier and more effective ways of stopping our fruits from going bad — but it might not be worth pouring it all down the drain. We may have not yet seen the good old aqua vitae’s full potential.

What makes my engine tick

Biofuels are nothing new. Historically cars used to run on all kinds of combustible liquids. In fact pure ethanol powered Henry Ford’s first car, the Quadricycle — it only fell out of favor during the Prohibition due to gasoline being cheaper². Contemporary gasoline all over the world usually contains at least some ethanol. Brazil went even further — all new vehicles sold there are flexfuel-capable, meaning they can run on a blend of gasoline and ethanol in pretty much any proportion. It makes sense — it lets Brazil shield itself from oil shortages and cut CO₂ emissions. In fact ethanol is superior to gasoline in many regards: it is more resistant to knock, allowing running higher compression ratios for higher efficiency and more torque; its air-fuel ratio is better, allowing extracting more power from a given cylinder volume; it burns cleaner and has much lower carbon footprint³; it makes the engine run cooler⁴; and finally it’s fully renewable. The only issue is its energy density, which is around 67% of gasoline, meaning the engine has to burn more fuel to produce the same power. It’s a no-brainer⁵. Since ethanol is much cheaper to produce now than gasoline⁶, it seems like the only thing stopping us from switching over is the fact that we got used to the status quo.

What fuels the cells

Combustion, however cozy and heartwarming, is not the only way of extracting energy back out of alcohol (or rather alcohols in general). Fuel cells can convert alcohol into electricity — either directly⁷ or indirectly — and do it easily and efficiently. They may not outperform hydrogen fuel cells, but since hydrogen is notoriously difficult to store, the lower cost of infrastructure for liquid fuels is a huge advantage. Even more importantly, it is possible to produce alcohols electrochemically — and that method is currently being intensively researched⁸. If it proves to be effective, it will open another possibility of storing energy from renewable sources, further smoothing out the fluctuations in available power.

Fuel for freedom

The most unexpected benefit comes from the low-tech nature of ethanol. It is always available — you just need to mix water and something that contains sugar, let the wild yeast ferment the mash, and then distill the mash using something as simple as a clay retort placed in the middle of a bonfire. Compared to the complexity of refining crude oil, this is trivial — anyone can do it anywhere. This means that in the event of a zombie apocalypse Brazil will have the highest number of cars still on the road, but it also means that individuals can still make their own fuel in case of an oil shortage, war or global economic collapse. It is impossible to ban, and no corporation can control the whole supply chain tightly enough to force everyone to buy their product. Moreover, the advances in the fuel cell technology and electrochemical synthesis it might actually allow people to efficiently make ethanol with just as much as a single solar panel. That’s as close to self-sufficiency as it gets!

Quite ironically, the same substance that harms so many and has been used by oppressors to control the oppressed⁹, might actually pave the way to a greener, more decentralized and more free future. Here’s to a brighter tomorrow!

Alcohol is AMAZING, Kurzgesagt - In a Nutshell ↩
Thus says Wikipedia. ↩
The Truth About Ethanol and Carbon Emissions, Renewable Fuels Association ↩
Cool. ↩
Some people claim that ethanol has a tendency to destroy engines. This is mostly untrue, with the exception of rubber tubing on old cars that tends to crumble after prolonged contact with ethanol. Fortunately it’s easy to fix - just replace it. All the hoses are now manufactured with ethanol content in mind. The other claim that ethanol has a corrosive effect on aluminium due to accumulation of water is questionable at best. Aluminium passivates itself quickly in contact with air, and the resulting aluminium oxide does not react with either water or ethanol under normal conditions. ↩
Cost of production of one gallon of ethanol, estimated to $0.90 vs cost of production of one gallon of gasoline, estimated to $2.70. ↩
Direct-ethanol and direct-methanol fuel cells are relatively simple to build and promise a 97% theoretical efficiency. Improving actual efficiency is a subject of research. ↩
Papers on synthesis of methanol and ethanol. ↩
Russia is the prime example, but similar measures were implemented on Polish lands occupied by tsarist Russia after Partitions of Poland. Also the now-outlawed practice of paying workers with alcohol instead of money in South Africa is considered by many to have been a form of deliberate oppression. ↩

Turning type-level magic into money

Mon, 22 May 2023 00:00:00 +0000

Money, money, money

Every single one of us handles money-related code at some point in time — be it because of the particular domain we work on, our own convenience, or just as a mental exercise. Regardless of the motivation, we all learn sooner or later that this is a surprisingly non-trivial topic, especially that it’s critically important to do everything right.

We’ve all been there

Let’s say we have some cash in different currencies, and wish to know how much dollars these amount to. A naive model could look like this:

@main def run =
  val pounds: BigDecimal = 2.0
  val exchange: BigDecimal = 1.2 //Bad naming!
  val dollars = pounds * exchange
  val savingsDollars: BigDecimal = 3.0

We all know how it ends:

  val dollarsInCash = dollars + savingsDollars
  val dollarsInCashAndFromExchange = dollars + savingsDollars + exchange //Horribly wrong!
  println(s"Dollars from selling pounds: $dollars, from savings: $savingsDollars. Total: $dollarsInCash")

A mistake that could be fixed with better naming, one could argue — the problem however is that this bug is especially hard to spot, and nothing helps us to do so!

Enter the Model

Let’s address that issue, and give our values a proper representation:

case class Money(value: BigDecimal)
case class Rate(rate: BigDecimal)

Now confusing an exchange rate with money should not be possible, at least on the surface. Let’s look at the usage:

@main def run =
  val pounds: Money = Money(2.0)
  val poundsToDollars = Rate(1.2)
  val dollars = pounds.value + poundsToDollars.rate

Turns out wrapping values in domain classes enforces nothing if the first thing we have to do in order to perform any sensible operation is to unwrap the values manually. The next step is to enrich the model with combinators:

case class Money private(value: BigDecimal):
  def +(other: Money): Money = Money(value + other.value)
  def exchange(rate: Rate): Money = Money(value * rate.rate)
  override def toString = value.toString
case class Rate(rate: BigDecimal)

Now we are safe.

Or are we?

Foiled again

@main def run =
  val pounds: Money = Money(2.0)
  val poundsToDollars = Rate(1.2)
  val dollars = pounds.exchange(poundsToDollars)
  val dollarsInCash = pounds + dollars

Our model misses some crucial information — there are several different currencies that cannot be added, at least not without converting them first. Modeling this information is straightforward:

case class Currency(name: String):
  override def toString = name
case class Money(value: BigDecimal, currency: Currency):
  def +(other: Money): Money =
    if currency == other.currency
    then Money(value + other.value, currency)
    else throw IllegalArgumentException(s"Mismatched currencies: $currency and ${other.currency}")
  def exchange(rate: Rate): Money =
    if currency == rate.from
    then Money(value * rate.rate, rate.to)
    else throw IllegalArgumentException(s"Mismatched currencies: $currency and ${rate.from}")
case class Rate(rate: BigDecimal, from: Currency, to: Currency)

Now, should anyone try to add mismatching currencies or convert money using a wrong rate, a nasty exception would be thrown in their faces.

@main def run =
  val gbp = Currency("GBP")
  val usd = Currency("USD")
  val pounds = Money(2.0, gbp)
  val poundsToDollars = Rate(1.2, gbp, usd)
  val dollars = pounds.exchange(poundsToDollars)

  //These two blow up!
  val totalCash = pounds + dollars
  val dollarsToPounds = dollars.exchange(poundsToDollars)

All is good

As we can see, a relatively simple model of the domain can make our lives so much simpler, saving us from wasting hours (if not days) of debugging to find a simplest mistake possible.

As a final touch, let’s get rid of the exceptions in favor of a more sensible error handling mechanism:

case class Currency(name: String):
  override def toString = name
case class Money(value: BigDecimal, currency: Currency):
  def +(other: Money): Either[MismatchedCurrencies, Money] =
    if currency == other.currency
    then Right(Money(value + other.value, currency))
    else Left(MismatchedCurrencies(currency, other.currency))
  def exchange(rate: Rate): Either[MismatchedCurrencies, Money] =
    if currency == rate.from
    then Right(Money(value * rate.rate, rate.to))
    else Left(MismatchedCurrencies(currency, rate.from))
case class Rate(rate: BigDecimal, from: Currency, to: Currency)
case class MismatchedCurrencies(c1: Currency, c2: Currency)

…or is it?

def calculateUSIncomeTax(dollars: Money): Money =
  //Skipping the implementation, as taxes are ridiculously complicated
  ???

@main def run =
  val gbp = Currency("GBP")
  val usd = Currency("USD")
  val pounds = Money(2.0, gbp)
  val tax = calculateUSIncomeTax(pounds)

There is nothing we can do to prevent passing a wrong currency into a wrong place. Even worse, if the calculateUSIncomeTax implementor did not place a check inside, we would have no clue what went wrong. The nightly debugging session we worked so hard to prevent seems inevitable.

In addition, switching from exceptions to Either made our API a bit less convenient — now we have to use pattern matching or for-comprehensions everywhere, and cannot chain our operations as nicely as previously:

@main def run =
  val gbp = Currency("GBP")
  for
    pounds <- Money(10, gpb) + Money(11, gbp)
    morePounds <- pounds + Money(0.37, gbp) //We cannot do `Money(10, gbp) + Money(11, gbp) + Money(0.37, gbp)` anymore!
  yield morePounds

Can we somehow make the implementation safer? Or at least get the nice API back?

Phantom menace

The answer is yes — if you wish to sell your soul to the type-level devil and let the compiler check the validity of your operations. First let’s lift the currency information into the type level:

sealed trait Currency
sealed trait GBP extends Currency
sealed trait USD extends Currency
sealed trait CHF extends Currency

Then let’s add some type parameters to our Money and Rate classes:

case class Money[A](value: BigDecimal):
  def +(other: Money[A]): Money[A]
  def exchange[B](rate: Rate[A, B]): Money[B] =
    Money(value * rate.rate)
case class Rate[A, B](rate: BigDecimal)

These type parameters don’t serve any purpose except distinguishing between different currencies, and don’t interact in any way with the “value” world — - therefore we call them “phantom type parameters”. Now we can observe that invalid additions and conversions are no longer possible:

@main def run =
  val pounds = Money[GBP](2.0)
  val dollars = Money[USD](3.0)
  //pounds + dollars //Does not compile!
  val poundsToDollars = Rate[GBP, USD](1.2)
  val total = pounds.exchange(poundsToDollars) + dollars
  //dollars.exchange(poundsToDollars) //Does not compile!
  //val money: Money[GBP] = Money[CHF](2.0) //Does not compile!

We both have prevented invalid behavior at compile time and regained our nice API!

The price

We have, however, lost a couple of things. First, we cannot display our Money objects nicely anymore, since the currency info is no longer just a value, but instead a type parameter that ceases to exist at runtime; second, the implementation became less elegant, as now we have a dedicated trait hierarchy just for marking our Money while most likely still needing the value-level representation for different use cases. The former is an easily fixable detail, the latter is a sacrifice we might be willing to make when safety is critical.

Singleton of Scalatown

There is one more thing that we can do, a trick that relies on an obscure, borderline black magic Scala feature. If you are satisfied with the solution above, feel free to skip the rest — otherwise fasten your seatbelts and abandon all hope.

Enter the singleton types.

When we think about types, our intuition tends to revolve around sets of values that share some common traits, constraints or behaviors. The Ints are plain integers from a certain range, Strings are sequences of characters, various object types are whatever we want them to be. Some of these sets of values are subsets of other, broader sets — establishing a relationship we call “subtyping”. This intuition does not prevent us from constructing types inhabited by a single value (or none, for what it’s worth); so when we reverse our thinking, every single value gives rise to a distinct type - a type that we might interpret as a restriction “values of this type are only this single, specific thing”. Scala 2.13 introduced this notion to its type system¹, allowing for constructs like:

val thisIs213: "213" = "213"
def doSomethingWith213(argument: "213"): String =
  s"$argument is 213, as it cannot be anything else"

Thanks to this we can impose restrictions of power previously unknown, and we can refine our Money model even further:

case class Currency(name: String):
  override def toString = name
case class Money[A](value: BigDecimal, currency: A):
  def +(other: Money[A]) = Money(value + other.value, currency)
  def exchange[B](rate: Rate[A, B]): Money[B] =
    Money(value * rate.rate, rate.to)
  override def toString = s"$value $currency"
case class Rate[A, B](rate: BigDecimal, from: A, to: B)

@main def run =
  val gbp = Currency("GBP")
  val usd = Currency("USD")
  val pounds = Money[gbp.type](2.0, gbp)
  val poundsToDollars = Rate[gbp.type, usd.type](1.2, gbp, usd)
  val dollars: Money[usd.type] = pounds.exchange(poundsToDollars)
  //println(pounds + dollars) //Does not compile!
  //println(dollars.exchange(poundsToDollars)) //Does not compile!
  //val dollarsAgain: Money[usd.type] = pounds //Does not compile!

We can now freely add new currencies as we go, we have retained our nice API², and we are as safe as it gets!

What’s the value of a singleton type?

The example above has the downside of unnecessary constructor parameters. We’d like to get rid of them, but that would mean our overloaded toString wouldn’t work again. Fortunately, retrieving a value of a singleton type should be quite simple — and indeed, Scala provides us with a nice way of doing exactly that. With the ValueOf context bound we can rewrite our code into its final form (taking the liberty to organize stuff a bit):

//Here's our model:
case class Currency(name: String):
  override def toString = name

case class Money[A: ValueOf](value: BigDecimal):
  def +(other: Money[A]) = Money(value + other.value)
  def exchange[B: ValueOf](rate: Rate[A, B]): Money[B] =
    Money(value * rate.rate)
  def exchangeFor[B: ValueOf](using rate: Rate[A, B]): Money[B] =
    exchange(rate)
  //The `ValueOf` context bound effectively marks our type as a singleton type.
  //By its virtue we get the `valueOf` method, which allows summoning the value of our singleton type.
  override def toString = s"$value ${valueOf[A]}"

case class Rate[A, B](rate: BigDecimal):
  def andThen[C](other: Rate[B, C]): Rate[A, C] =
    Rate(rate * other.rate)

//We can define our custom apply for convenience:
object Money:
  def apply(value: BigDecimal, currency: Currency): Money[currency.type] =
    Money(value)

//And some example values:
object Currencies:
  val gbp = Currency("GBP")
  type GBP = gbp.type
  val usd = Currency("USD")
  type USD = usd.type
  val chf = Currency("CHF")
  type CHF = chf.type

object Rates:
  import Currencies.*
  given Rate[GBP, USD] = Rate(1.2)
  given Rate[USD, CHF] = Rate(0.9)
  given transitiveRate[A: ValueOf, B, C: ValueOf](using r1: Rate[A, B], r2: Rate[B,C]): Rate[A, C] =
    r1.andThen(r2)

@main def run =
  import Currencies.*
  import Rates.given
  val pounds: Money[GBP] = Money(2.0)
  val alsoPounds = Money(2.0, gbp) //using the convenience apply method
  val dollars = pounds.exchangeFor[USD]
  val francs = pounds.exchangeFor[CHF]

With this technique we have forced the compiler to check the correctness of our domain logic — the benefits are hard to overstress. And all that thanks to a simple concept!

A detailed description of the feature ↩
There is a limitation to this — singleton types rely on the notion of a stable path, so Currency("EUR").type unfortunately is not a valid singleton. It also means that val eur1 = Currency("EUR") and val eur2 = Currency("EUR") give rise to two different singleton types. ↩

A primer on Readers

Sat, 27 Aug 2022 00:00:00 +0000

The dream

Imagine we have functions:

def f: A => B = ???
def g: B => C = ???
def h: C => D = ???

The implementation may be whatever we want it to be, these functions might parse some data, perform calculations, format strings et cetera. Now, often we want to chain multiple operations together — ie. parse a JSON with sales data, then extract monthly sales figures and finally output an average. After all, coding is all about gluing blocks together to create a useful program. We could, of course, write h(g(f(x))) each time we want the whole functionality, but if it’s used frequently, giving it a proper name is a good idea. Scala gives us many different ways of gluing functions together, but I’m going to stick to the andThen from Function1 trait — because it behaves almost like the mathematical ∘ operator, just in reverse order¹. With it creating a function i: A => D is as simple as writing:

def i: A => D = f andThen g andThen h

The reality

This kind of composition, obviously, works only for functions with one argument — with multi-argument functions we quickly run into a world of trouble. Quite unfortunate, since the vast majority of those we encounter on a daily basis need more than one input. But what if all of our functions look like this?:

def f: E => A => B = ???
def g: E => B => C = ???
def h: E => C => D = ???

This is again a common thing — oftentimes we need to pass some sort of a context (or other dependency) to our methods. It would be useful to be able to compose them, even if just to save us some writing. They share the type of the first argument — it must have made our task easier. What do we need to do to be able to compose them in a sensible way?

The promise

First of all, let’s simplify things a bit and imagine a function that magically reads some value V from an environment E. It’s going to have a type E => V. We’re going to call it Reader for precisely that reason, and we’re going to wrap it in a case class for convenience:

case class Reader[E, V](read: E => V)

We’re halfway there, we just need to notice that function parameters should be swappable (with possible minor tweaks to the logic inside — but usually we don’t depend on their order anyway). Then we can rewrite our f, g, and h as:

def f: A => E => B = ???
def g: B => E => C = ???
def h: C => E => D = ???

There’s a lot of Readers just waiting in line. We can now rewrite our functions again:

def f: A => Reader[E, B] = ???
def g: B => Reader[E, C] = ???
def h: C => Reader[E, D] = ???

The solution

Now we just need to compose these somehow. First of all, let’s give our Reader a helper method:

case class Reader[E, V](read: E => V) {
  def pipeTo[W](other: V => Reader[E, W]): Reader[E, W] = Reader { env =>
    val result1 = read(env)
    other(result1).read(env)
  }
}

Then we can make ourselves a helper:

object Reader {
  implicit class ReaderOps[E, A, B](f1: A => Reader[E, B]) {
    def andThenR[C](f2: B => Reader[E, C]): A => Reader[E, C] =
      a => f1(a).pipeTo(f2)
  }
}

Et voilà, we can now write this:

def i: A => Reader[E, D] = f andThenR g andThenR h

And it works!

A bit of black magic

We can do one more trick. Let’s first refactor the Reader to be able to use Scala’s wonderful for-comprehensions by renaming pipeTo to flatMap and adding a map method²:

case class Reader[E, V](read: E => V) {
  def map[W](f: V => W): Reader[E, W] = Reader(env => f(read(env)))
  def flatMap[W](f: V => Reader[E, W]): Reader[E, W] = Reader { env =>
    val result1 = read(env)
    f(result1).read(env)
  }
}

and then define:

def ask[E]: Reader[E, E] = Reader(identity)

Now we can write stuff like this:

val readIncrementAndStringify = for {
  intFromEnvironment <- ask[Int]
  incremented = intFromEnvironment + 1
} yield s"$incremented"

This yields a Reader[Int, String] value, which we can run afterwards to retrieve the final String when we need it — but the logic itself looks like pulling Ints out of thin air. Beautiful, isn’t it?

The use

One might ask: why does it matter at all? Aside of the obvious, this can serve as a dependency injection mechanism — functional and type safe. The E we plug into the Reader can be whatever we want — a default value for a given type, an input to a whole computation, a validator or a service with various utilities. We can even stuff multiple things into it!

type Env = (UserDeserializer, UserValidator)

def createUser(input: String): Reader[Env, Option[User]] = for {
  (deserializer, validator) <- ask[Env] //assuming we use better-monadic-for plugin. Who doesn't?
  deserialized = deserializer.deserialize(input)
  isCorrect = validator.validate(deserialized)
} yield if (isCorrect) Some(deserialized) else None

This idea is quite similar to how ZIO handles dependency injection³, and how it’s often done in the wide functional world. Of course this implementation is quite limited — but its purpose is to give the reader (pun intended) an intuition on how Readers work.

So to sum up: Reader is simply a functional programming pattern for composing two-argument functions that share one of its arguments, and it can be used for anything from passing common values around with less clutter to full-blown dependency injection. Go forth and read!

Scala also defines the compose method that behaves exactly like mathematical function composition, but andThen is usually easier to follow, as it reflects the exact order of function application. ↩
Now it becomes clearer why we decided to wrap our E => V function instead of relying on plain Function1 — we want to have map and flatMap methods available. ↩
ZIO defines the ZIO[R, E, A] type, which uses the R type parameter to pass dependencies around in a Reader-esque fashion. For detailed explanation see:
↩