Either Disjoint Or Union Types

Many languages support union types, and it is high time Scala did. Union types are coming in upcoming version of Scala – Dotty. Union types (|) are already being compared with Either and Option (disjoint unions).

In some ways, Either and Option may be expressed as union types.

// Option[String]
String | null

// Either[Int, String]
Int | String

Similar to disjoint union types, you can pattern match over Union types. However, the differences outshine the similarities.

Disjoint union types like Either and Option

  • constraint the universe of types to be unique – Left and Right, Some and None. There is only one Left or Some.
  • can be parameterized – Either[L, R] , Option[T]
  • Defined in the standard library. Not language syntax.

On the other hand, Union Types (|) …

  • Not parameterized. Types are specific.

  • The types involved don’t have to be necessarily unique.

    String | Int | String | Int
    

    The above definition is valid although the universe of types is just String and Int.

  • Language syntax

There is one difference that stands out to me, in fact of disjoint union types. Either and Option are monads and so they give the niceties of map, flatMap and all those of a container. Can’t do that with Union types.

Update: Per phazer99‘s reddit comment, union types could be augmented with extension methods to get the map and flatMap. That’s interesting although I feel it does not make it truly monadic. For instance, what is the unit value? Will the monad laws hold good? Happy to stand corrected.

However, Union types give you edge over one thing. In fact, the thing I don’t like about Either or Option; or JVM in general. Disjoint union types are allocated on the heap; every instance. Union types are compile time construct and do not require extra allocation.

As you can see, grass is greener on either side. Both disjoint union and Union types have their place and are here to stay. You gotta choose the right one for the job; Either disjoint types | Union Types!

Know Thy Option

A thing or two about Option

  • Avoid .get at all costs. Forget there is even a .get function on Option. There is always an alternative to .get. Same applies to .head
  • If you are going to have access the value in an Option in a test class1, prefer extending your test class from OptionValues. Then you can use .value on an Option, which fails with a relatively better error message if the value is not defined.
  • Option maybe viewed as a sequence (of zero or one element). This is for convenience when working with Option, which is why see a .head on an Option.

Continue reading Know Thy Option

Non-FP to FP Conversion Caveat

Sometimes you learn the best from others; by watching. This post is based on such an instance. A fellow engineer on my team was investigating a nagging issue – partially-successful operations or rather operations that left data in an inconsistent state. It goes without saying that I take no credit for the time and effort spent on the investigation nor for the fix. I am just the messenger. And as a responsible programmer 🤓, I am sharing it with the rest of the world.

We use Scala in my team and have been trying to be (pure) functional (as much). Hmmm … trying to be functional? Yeah, because the truth is not always black and white.

Continue reading Non-FP to FP Conversion Caveat

A Rambling on Error Handling

In the early years, software applications were tiny, compared to what we build today. In any given application, one could say, there were only a handful of error scenarios to deal with. Besides, error reporting, if not error handling, lacked finesse. Just slap the user with something red enough, and just say An error occurred.

Continue reading A Rambling on Error Handling

JS Programming in C# – Immutability

Enough! JavaScript had us in its grip for long with its foot guns. The first time I heard the term Hoisting, I had no idea about it and misheard as hosting. You declare variables using var happily, and you have to come to peace with yourself that it is okay to hoist the vars (lift’em all to the top-most scope). I can’t believe JS convinced the rest of us that it was okay. Then came ES6 and saved us. let fixed the scoping. const provided immutability. At least now, you can say JavaScript supports functional programming.

JavaScript got feathers on its hat – let and const.

Continue reading JS Programming in C# – Immutability

Facets of Immutability

Immutability, the cornerstone of functional programming, has many facets.

Not every (mainstream) language supports all the facets; at least not per what each facet stands for. That’s what I will talk about today. The various facets of immutability from a theoretical perspective, and briefly show how some of the mainstream languages have adopted and support these facets in their own way.

Continue reading Facets of Immutability