Importance of isomorphic functions

Question

Short Question: What is the importance of isomorphic functions in programming (namely in functional programming)?

Long Question: I'm trying to draw some analogs between functional programming and concepts in Category Theory based off of some of the lingo I hear from time-to-time. Essentially I'm trying to "unpackage" that lingo into something concrete I can then expand on. I'll then be able to use the lingo with an understanding of just-what-the-heck-I'm-talking about. Which is always nice.

One of these terms I hear all the time is Isomorphism, I gather this is about reasoning about equivalence between functions or function compositions. I was wondering if someone could provide some insights into some common patterns where the property of isomorphism comes in handy (in functional programming), and any by-products gained, such as compiler optimizations from reasoning about isomorphic functions.

Answer 1

I take a little issue with the upvoted answer for isomorphism, as the category theory definition of isomorphism says nothing about objects. To see why, let's review the definition.

Definition

An isomorphism is a pair of morphisms (i.e. functions), f and g, such that:

f . g = id g . f = id 

These morphisms are then called "iso"morphisms. A lot of people don't catch that the "morphism" in isomorphism refers to the function and not the object. However, you would say that the objects they connect are "isomorphic", which is what the other answer is describing.

Notice that the definition of isomorphism does not say what (.), id, or = must be. The only requirement is that, whatever they are, they also satisfy the category laws:

f . id = f id . f = f (f . g) . h = f . (g . h) 

Composition (i.e. (.)) joins two morphisms into one morphism and id denotes some sort of "identity" transition. This means that if our isomorphisms cancel out to the identity morphism id, then you can think of them as inverses of each other.

For the specific case where the morphisms are functions, then id is defined as the identity function:

id x = x 

... and composition is defined as:

(f . g) x = f (g x) 

... and two functions are isomorphisms if they cancel out to the identity function id when you compose them.

Morphisms versus objects

However, there are multiple ways two objects could be isomorphic. For example, given the following two types:

data T1 = A | B data T2 = C | D 

There are two isomorphisms between them:

f1 t1 = case t1 of     A -> C     B -> D g1 t2 = case t2 of     C -> A     D -> B  (f1 . g1) t2 = case t2 of     C -> C     D -> D (f1 . g1) t2 = t2 f1 . g1 = id :: T2 -> T2  (g1 . f1) t1 = case t1 of     A -> A     B -> B (g1 . f1) t1 = t1 g1 . f1 = id :: T1 -> T1  f2 t1 = case t1 of     A -> D     B -> C g2 t2 = case t2 of     C -> B     D -> A  f2 . g2 = id :: T2 -> T2 g2 . f2 = id :: T1 -> T1 

So that's why it's better to describe the isomorphism in terms of the specific functions relating the two objects rather than the two objects, since there may not necessarily be a unique pair of functions between two objects that satisfy the isomorphism laws.

Also, note that it is not sufficient for the functions to be invertible. For example, the following function pairs are not isomorphisms:

f1 . g2 :: T2 -> T2 f2 . g1 :: T2 -> T2 

Even though no information is lost when you compose f1 . g2, you don't return back to your original state, even if the final state has the same type.

Also, isomorphisms don't have to be between concrete data types. Here's an example of two canonical isomorphisms are not between concrete algebraic data types and instead simply relate functions: curry and uncurry:

curry . uncurry = id :: (a -> b -> c) -> (a -> b -> c) uncurry . curry = id :: ((a, b) -> c) -> ((a, b) -> c) 

Uses for Isomorphisms

Church Encoding

One use of isomorphisms is to Church-encode data types as functions. For example, Bool is isomorphic to forall a . a -> a -> a:

f :: Bool -> (forall a . a -> a -> a) f True  = \a b -> a f False = \a b -> b  g :: (forall a . a -> a -> a) -> Bool g b = b True False 

Verify that f . g = id and g . f = id.

The benefit of Church encoding data types is that they sometimes run faster (because Church-encoding is continuation-passing style) and they can be implemented in languages that don't even have language support for algebraic data types at all.

Translating Implementations

Sometimes one tries to compare one library's implementation of some feature to another library's implementation, and if you can prove that they are isomorphic, then you can prove that they are equally powerful. Also, the isomorphisms describe how to translate one library into the other.

For example, there are two approaches that provide the ability to define a monad from a functor's signature. One is the free monad, provided by the free package and the other is operational semantics, provided by the operational package.

If you look at the two core data types, they look different, especially their second constructors:

-- modified from the original to not be a monad transformer data Program instr a where     Lift   :: a -> Program instr a     Bind   :: Program instr b -> (b -> Program instr a) -> Program instr a     Instr  :: instr a -> Program instr a  data Free f r = Pure r | Free (f (Free f r)) 

... but they are actually isomorphic! That means that both approaches are equally powerful and any code written in one approach can be translated mechanically into the other approach using the isomorphisms.

Isomorphisms that are not functions

Also, isomorphisms are not limited to functions. They are actually defined for any Category and Haskell has lots of categories. This is why it's more useful to think in terms of morphisms rather than data types.

For example, the Lens type (from data-lens) forms a category where you can compose lenses and have an identity lens. So using our above data type, we can define two lenses that are isomorphisms:

lens1 = iso f1 g1 :: Lens T1 T2 lens2 = iso g1 f1 :: Lens T2 T1  lens1 . lens2 = id :: Lens T1 T1 lens2 . lens1 = id :: Lens T2 T2 

Note that there are two isomorphisms in play. One is the isomorphism that is used to build each lens (i.e. f1 and g1) (and that's also why that construction function is called iso), and then the lenses themselves are also isomorphisms. Note that in the above formulation, the composition (.) used is not function composition but rather lens composition, and the id is not the identity function, but instead is the identity lens:

id = iso id id 

Which means that if we compose our two lenses, the result should be indistinguishable from that identity lens.