Comments on: Cozipping

By: Xplat

Xplat — Wed, 04 Aug 2010 20:03:21 +0000

Counzipping makes a pretty good toy model of the runtime type erasure that happens in Java and Scala generics — it pushes a tag from the root of a container down into the individual ‘holes’. Cases where the cozip doesn’t exist become unsafe ‘unchecked casts’. I wonder if this sort of analysis could be used as a basis for better compile-time analysis of where unsafety occurs.

By: Edward Kmett

Edward Kmett — Tue, 06 May 2008 01:00:58 +0000

You’re right, I flipped the names when I was slapping together the code over lunch. I had left my notes at home. I’ll fix it up.

Hrmm, of course now you need an extra ‘fair’ acounzip as well.

By: Twan van Laarhoven

Twan van Laarhoven — Tue, 06 May 2008 00:23:36 +0000

An interesting post, I was thinking along a slightly different (and wrong) route myself.

First of all, shouldn’t cozip be called counzip and vice-versa? fzip has type “(f a * f b) -> f (a*b)” doesn’t taking the dual give “(f a + f b) Either (f a) (f b)”?

I was thinking about the type

> almostcozip :: f (Either a b) -> (f a, f b)

This function can be implemented unambiguously for [] and Maybe, and is in quite useful in practice. It also has a right inverse,

> acounzip :: (f a, f b) -> f (Either a b)

If (f x) is a Monoid then
> acounzip (fa, fb) = fmap Left fa `mappend` fmap Right fb

Thinking about it some more, there is also the dual type

> azip :: Either (f a) (f b) -> f (a,b)
> aunzip :: f (a,b) -> Either (f a) (f b)

But I can’t think of any nice function with this type.