What I really wanted was a version of Smalltalk that used the same object modal as Objective-C, like Pragmatic Smalltalk of Etoilé, or even MacRuby on Mac OS. Most of all, I wanted it to treat me like an adult: I don’t need a class browser, thank you, I’m more comfortable working with plain-old files. The persistent image construct in Smalltalk really makes me uncomfortable.

Eventually, I found F-Script, a scripting environment for Mac OS based on Smalltalk. It is not really meant for developing full applications, but with a little work, I was able to make this work.

First, we will need a bare-bones Xcode project for an Objective-C application with a XIB. Remove all of the instance variables, outlets and properties from your application delegate. Before we go any further, we’ll need to create class in F-Script, which we will call WindowController. Create a new file WindowController.st in your Resources group. You may consider using TextMate for editing, because there are is an F-Script bundle you can use, whereas Xcode does not support highlighting of Smalltalk.

Writing the Smalltalk component

We need to define a class and its instance variables (I apologize for the mis-coloring of some code; my highlighter isn’t built for F-Script’s dialect of Smalltalk):

Note that comments are made by putting double-quotes around text.

Now, we can start writing the instance methods for this class. As always, we start with an initializer:

It doesn’t appear that F-Script supports making your own symbolic constants like Ruby, so I used instance variables set in -init instead.

Next, we need to have it create and present our window. The following code will show you how some plain C constructs used in Objective-C (like Cocoa graphics structs, &c.) map into F-Script:

At the end of -loadWindow we have a call to windowDidLoad, which is implemented as follows:

There were a few calls in -windowDidLoad to methods we need to implement. These will be a good example of the block-based control structures of Smalltalk, where -ifTrue, -ifFalse is a method:

Finally, we can’t forget to end our class: }..

Some notes on syntax

To declare local variables, we surround them in bars: | localVar1 localVar2 |. Note that like in Ruby, mathematical operators are really messages sent to the objects behind them.

Statements are ended with a period (.), but the semicolon (;) does something entirely different. In Objective-C, we might do the following:

in a Smalltalk variant, we can do this instead:

Linking WindowController with our application.

This is the last and most important part of this tutorial. We cannot use our Smalltalk code without somehow loading it from the Objective-C portion of our application.

F-Script includes a framework that facilitates executing blocks of F-Script code, and that is how we will combine our Smalltalk WindowController class with our Cocoa application. First, add FScript.framework to your Xcode project. Then, make sure your AppDelegate.h file imports it.

Now, in -applicationDidFinishLaunching:, you need to load our code into an FSBlock:

Now, you can create an instance of WindowController and use it (note that you must type your instance id, because this sort of hackery will not allow specific typing):

The beautiful thing here is that we called several methods (+alloc, -init, and -loadWindow) in Objective-C from a class created in Smalltalk. All this should make a window pop up that functions as we would expect it to:

Making it even easier!

Of course, if you have many Smalltalk classes to load, all this loading code can be quite a pain; naturally, I wrote a #define directive for it:

Caveats

Unless you somehow encode your Smalltalk files and then decode them at runtime, the code for the Smalltalk portion of your application will be available to any user smart enough to open your application package. Also, if you use the #define I gave you above, you must make each .st file have only one class, and have that class’s name match the name of the file.

Conclusion

I hope that this information and code brings joy not only to my fellow Smalltalk enthusiasts, but also to those Objective-C programmers who want an insight into the origins of their language.

Where is it that you really belong? You know you don’t belong here, and your worst fear is that everyone else knows this too. Everyone around you is comfortable, confident and excited for the future, and you’re living a dream. Someone else’s dream, one you can only watch others fulfill. As the years go by, the expectations of a high-schooler are proved to be justified, just not by you. By the people you used to hang out with, row boats with, study with.

Where is he? He’s moving and shaking simultaneously, so hard he can barely hear you. Every once in a while, he passes through your life; “You were going to be a scientist, right? That’s so cool,” he says. You don’t have the courage to tell him that you ended up becoming a paralegal, or a nurse’s assistant in Just Nine Months™, that your grand dreams for the future had to be put aside for whatever reason: you had a kid, you didn’t think you were good enough, you couldn’t afford the future.

Then he rides off in his motorcycle that he bought “because he felt like it”. Part of you wants to shave his trendy stubble with a chain-saw, but the other part wants to ask him how he got where he is, what you did wrong fifteen years ago. But as always, you don’t. You don’t ask him anything, you just say, “Man, it was so cool to see you again! We should get the old gang back together some day, talk about old times…”

“Yeah, man, that would be really cool. Well, I’ve gotta run. Diamonds wait for no man.” There is opportunity for the taking in Africa; you just have to see it! And you know you won’t see him again for another few years (unless stalking him on the Internet counts).

Like I said, you know who you are. Your problem is that you stole another man’s path, and were surprised when he took it back; I carved out my own. You don’t need to hide in a throng of geeks to be well-liked.

A ‘bag’ is a multiset, or a set which can contain duplicate objects. CoreFoundation includes CFBag, which is the same concept; for reasons of simplicity, JSBag was implemented on top of NSArray instead of CFBag, but it certainly would be possible if better performance were desired.

Traits

Really, they’re just protocols that have concrete implementations. The way this works is that when a JSBag object is created, the traits (such as mutability) that it needs to have are specified; there are default implementations of each of these traits included (the implementation is in the form of a class adopting the trait’s protocol), but these can be switched out for alternate implementations. You can even add your own traits.

The way this all works is that when the JSBag object receives a message, it looks through its enabled traits until it finds the one which declares a corresponding method; then, it will look through its traits-to-implementation-class map to find the class that implements that method. Then, it grabs the IMP from that class and applies it to self with whichever arguments are necessary.

Whereas in the traditional Class Cluster, the abstract superclass tends to spend a lot of time jiggering about how to delegate its unimplemented tasks, and the concrete subclasses tend to duplicate a lot of functionality among themselves, this system allows pluggable implementations for traits that can easily be turned on and off. So, the JSMutableBag subclass of JSBag actually only implements one method, which is to override the enabled traits to include @protocol(JSMutableBag). Other similar subclasses of JSBag could be created which add support for more, user-defined traits.

Drawbacks

The idea of this is not to use alternate implementations that carry down abstract bits from a superclass: the idea is to compose functionality by registering implementations of traits, and then dispatching tasks dynamically to them. That means that a few benefits of the traditional Class Cluster are lost, namely the ability for implementations to have alternative instance-variable layouts.

In the end, I think that the performance gain from that sort of optimization is going to be minimal for most things (remember, YAGNI). So, I believe that in many cases, a trait-composition design like that shown in JSBag could be useful.

Design

You may note that I’ve avoided using specific types of collections in my interface, because in most cases, all that matters is that they can be iterated over. Hence, instead of taking parameters of type NSArray* or NSSet* for some things, I’ve generalized to id <NSFastEnumeration>. Since JSBag adopts <NSFastEnumeration>, that means that methods which take collections as parameters can also take JSBag objects. This is incredibly useful, as it makes having methods like +bagWithArray:, +bagWithSet:, +bagWithBag:, etc. actually redundant:

+ (id)bagWithCollection:(id <NSFastEnumeration>)enumerable;

will handle all of this for us. This made implementing <NSCopying>, <NSMutableCopying>, and several other key bits absolutely trivial:

1
2
3
4
5
6
7

- (id)copyWithZone:(NSZone *)zone {
  return [[JSBag allocWithZone:zone] initWithCollection:self];
}

- (id)mutableCopyWithZone:(NSZone *)zone {
  return [[JSMutableBag allocWithZone:zone] initWithCollection:self];
}

Remember that messaging JSMutableBag vs. JSBag for in this case only changes the default enabled traits from {<JSBasicBag>} to {<JSBasicBag>,<JSMutableBag>}. That’s pretty cool.

Moving Forward

I believe that this trait-composition approach could be generalized to be usable in many contexts. As I improve it, and make it more flexible, I hope to find neat uses for it. In the meanwhile, clone or fork JSBag on Github!

Hence, my new shitlist.

1. Never embed your web application in a native application; that is to say, do not slap a webview above a UITabBarController and call it good. This is a sin.

2. Never use controls which attempt to mimic those of the substrate platfom: the bullshit interaction of your iPhone-y navigation bar will only serve to highlight your incompetence to experienced users, and confuse inexperienced ones.

3. Do not make some sort of header attempt to hover at the top of your view, unless you have coded your own scrolling system (like in PastryKit). All the time, I see bullshit websites that have some sort of terrible navigation bar that sits at the top of the view, no matter how far down you are scrolled; but because it is bullshit, when you start dragging to scroll, the header disappears, and reappears when scrolling has stopped. This is bullshit.

4. Don’t overuse animation. WebKit has some neat stuff these days, and in an attempt to make web apps feel at home, some devs insist of using view animations (like in an iOS navigation controller). Don’t do this: it’s often laggy, and takes away from the speed of a transition that ought to be instant! When I do something in a native navigation controller, I expect some animation-feedback; when I tap a link in a website, I expect to brought immediately to my destination.

5. Don’t, for the love of God, try to make it look like iOS. The whole reason for web applications is that your don’t have to spend resources building a separate app for each platform. If you are content to force all users, regardless of their platform, to use an app that looks like you disemboweled iOS and filled her with bullshit, then you ought to just make a nice native app for iOS and ignore the other platforms.

Note: @stevestreza, the creator of the awesome web app Swearch, informs me that it’s possible to make WebKit animations 60fps on iPhone 3GS and up, if you code them the hell properly. The problem is that most developers do a poor job at this, I suppose.

What you must do.

If you must make a mobile web app, make it as simply as possible, without lots of custom controls. In fact, just try to make it exactly like Pinboard; 37signals also did a great job with Basecamp (though I disagree with their use of animated transitions). Last thing: for the sake of iOS users, please make sure that your app is capable of being clipped to the home screen and opening in its own chromeless browser.

I’ve seen a few solutions to this problem; the one that came closest ended up overriding

1
2

-[NSSliderCell startTrackingAt:inView:],
-[NSSliderCell continueTracking:at:inView:]

and cleverly switching allowsTickMarkValuesOnly on and off at opportune moments. This worked visually, but the data that was streamed from the slider didn’t actually snap until after tracking ended. This is obviously a non-starter, if you’re showing continuous feedback for your slider.

My solution

So, I’ve come up with a simpler and slightly more clever solution, which behaves just as one would expect it to.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

@interface JSSnappingSliderCell : NSSliderCell
@end

@implementation JSSnappingSliderCell
static const CGFloat kSnappingZone = 10.0f;

- (BOOL)continueTracking:(NSPoint)lastPoint at:(NSPoint)currentPoint inView:(NSView *)controlView
{
  CGPoint snapToPoint = currentPoint;

  for (NSUInteger i = 0; i < self.numberOfTickMarks; i++)
  {
    NSRect tickMarkRect = [self rectOfTickMarkAtIndex:i];
    if (ABS(tickMarkRect.origin.x - currentPoint.x) <= kSnappingZone)
    {
      snapToPoint = [self rectOfTickMarkAtIndex:i].origin;
      break;
    }
  }

  return [super continueTracking:lastPoint at:snapToPoint inView:controlView];
}

@end

Enjoy, and do let me know if you have a better idea!

In the untyped lambda calculus, a pair (x, y) is encoded as a function which takes two values x, y, yielding a new function that takes an accessor function f as its argument (that is, f selects either the left or the right argument):

$\begin{aligned} \textbf{pair} &:= \lambda xyf. f\,xy\\ \textbf{fst} &:= \lambda p. p\, (\lambda xy. x)\\ \textbf{snd} &:= \lambda p. p\, (\lambda xy. y) \end{aligned}$

So, the following reductions can occur:

$\begin{aligned} \textbf{pair}\; ab &\equiv (\lambda xyf. f\,xy)\; ab\\ &\to \lambda f. f\,ab\\ \textbf{fst}\; (\textbf{pair}\; ab) &\equiv \textbf{fst}\; (\lambda f. f\,ab)\\ &\to (\lambda p. p\, (\lambda xy. x))\; (\lambda f. f\,ab)\\ &\to (\lambda f. f\,ab)\; (\lambda xy. x)\\ &\to (\lambda xy. x)\; ab\\ &\to a\\ \textbf{snd}\; (\textbf{pair}\; ab) &\equiv \textbf{snd}\; (\lambda f. f\,ab)\\ &\to (\lambda p. p\, (\lambda xy. y))\; (\lambda f. f\,ab)\\ &\to (\lambda f. f\,ab)\; (\lambda xy. y)\\ &\to (\lambda xy. y)\; ab\\ &\to b\\ \end{aligned}$

Translating our untyped example into the typed lambda calculus naïvely doesn’t change much of anything. The main features of this new calculus are polymorphic types (α, β, γ…), and type-level functions corresponding to universal quantification. Types are abstracted over using a capital lambda.

$\begin{aligned} \textbf{pair} &:= \Lambda\alpha\beta\gamma. \lambda (x : \alpha) (y : \beta) (f : \alpha\to\beta\to\gamma). f\,xy\\ \textbf{fst} &:= \Lambda\alpha\beta\gamma. \lambda (p : {(\alpha\to\beta\to\alpha)\to\gamma}). p (\lambda (x : \alpha) (y : \beta). x)\\ \textbf{snd} &:= \Lambda\alpha\beta\gamma. \lambda (p : {(\alpha\to\beta\to\beta)\to\gamma}). p (\lambda (x:\alpha) (y:\beta). y) \end{aligned}$

However, this is problematic. What this definition of pair ends up saying is that for all types α, β, γ, there is a function that will retrieve a value in γ from a pair in (α, β). This, however, is only true inasmuch as γ is either α or β. Thus, our current definition will allow more incorrect programs than is acceptable in a typed (but not dependently-typed) language. What we really need is to constrain γ:

$\begin{aligned} \textbf{pair} &:= \Lambda\alpha\beta. \lambda (x:\alpha) (y:\beta) (f:{\alpha\to\beta\to(\alpha\lor\beta)}). f\,xy\\ \textbf{fst} &:= \Lambda\alpha\beta. \lambda (p:{(\alpha\to\beta\to\alpha)\to\alpha}). p (\lambda (x:\alpha)(y:\beta). x)\\ \textbf{snd} &:= \Lambda\alpha\beta. \lambda (p:{(\alpha\to\beta\to\beta)\to\beta}). p (\lambda (x:\alpha)(y:\beta). y) \end{aligned}$

So, we have created a typed encoding of the Church Pair which only allows accessors which return a value of the correct type.

Encoding our typed Church Pair in Haskell

> {-# LANGUAGE MultiParamTypeClasses #-}
> {-# LANGUAGE Rank2Types #-}
> {-# LANGUAGE FlexibleInstances #-}
> {-# LANGUAGE IncoherentInstances #-}
> {-# LANGUAGE UnicodeSyntax #-}

> module ChurchPair where
> import Prelude hiding (fst, snd)

The first order of business will be to implement the disjunction constraint (Λ αβ. α ∨ β) in Haskell. To do this, we can use a type class:

> class TypeOr α β γ

and inhabit it with the proper combinations:

> instance TypeOr α β α
> instance TypeOr α β β

Now, we can create a type synonym (for the sake of convenience) that encapsulates the structure of pairs:

> type Pair α β = ∀ γ. TypeOr α β γ ⇒ (α → β → γ) → γ

A Pair over (α, β) is function that takes a function that returns one of its elements. Note that we cannot specify within this non-dependent type system that the result of this accessor actually be one of the elements, but the (TypeOr α β γ) constraint allows us to at least ensure that the result is of the type of either element in the pair.

And now, given two values, we can construct a Pair:

> pair :: α → β → Pair α β
> pair x y f = f x y

The accessors are easily written, and their type annotations make clear their function:

> fst :: Pair α β → α
> fst p = p $ \x y → x

> snd :: Pair α β → β
> snd p = p $ \x y → y

Incidentally, fst and snd can also be defined in terms of library functions:

> fst' p = p const
> snd' p = p $ flip const

To demonstrate the benefit our typing constraints, try the following:

badAccessor :: Pair α β → String
badAccessor p = p $ \x y → "Hello" -- type error

It is impossible to create an accessor of the wrong type (unless the accessor itself is the bottom, in which case you will have a runtime error).

Building on the work of sigfpe’s From Monoids to Monads and monoidal’s Kind polymorphism in action (which demonstrates kind polymorphism in the Ultrecht Haskell Compiler), we can unify Monoid and Monad under one type class in GHC 7.4.

So, the quote at the beginning is true, but with a few qualifications. As most beginning functional programmers know it, the monoid is a structure that has an identity element id and a binary operator  ⊗ :

$\begin{aligned} \text{class} &\textbf{Monoid}\ (m : \star) \text{ where}\\ & id: m\\ & \otimes: m \to m \to m \end{aligned}$

For the monoid m to be valid, the id must be the identity with respect to the operator  ⊗ , like 0 is to  +  on natural numbers, or 1 to  × , etc; the binary operator must also be associative:

$\begin{aligned} \forall x &: m.\ &x\otimes id &\equiv id\otimes x \equiv x\\ \forall a,b,c &: m.\ &(a\otimes b)\otimes c &\equiv a\otimes (b\otimes c) \end{aligned}$

This kind of monoid does not bear the sort of abstraction required to unify it with Monad, which is rather different:

$\begin{aligned} \text{class} &\textbf{Functor}\ m \Rightarrow \textbf{Monad}\ (m : \star\to\star) \text{ where}\\ & \eta: \forall\alpha:\star. (\textbf{Id}\ \alpha \to m\,\alpha) \\ & \mu: \forall\alpha:\star. (m\, (m\,\alpha) \to m\,\alpha) \end{aligned}$

In fact, η is a natural transformation¹ from the Identity functor to another functor m; μ is a natural transformation from m² to m (that is, from m applied twice to m applied once).

A Difference of Kinds

You’ll note that our Monad and Monoid operate in totally different worlds: a difference of kinds. That is, an instance of the former is a type of values (m:  ⋆ ), whereas an instance of the latter is an arrow from one type to another (a type constructor, m:  ⋆  →  ⋆ ). By analogy, then, the former’s functions should be natural transformations in the latter.

This makes fine sense, but the question of what to do with id remains: why does it have an input in Monad, but not in Monoid? If we are going to understand these functions as arrows between objects in a category, then id must have an input. As a natural transformation in Monad, its input is the identity functor; as a simple function in Monoid, its input should be $\varnothing$, nothing.

If we uncurry  ⊗ , then its type becomes (m × m → m); this adjustment brings its type in line with that of μ. So, we can build the following (incomplete and flawed) generalization over an identity element id and a type-operator  × :

$\begin{align} \text{class} &\textbf{Monoid}\ (id: k)\ (\times : k\to k\to \star)\ (m : k)\ \text{ where}\\ & id: id \to m\\ & \otimes: m\times m \to m \end{align}$

$\begin{align} \text{instance} &\textbf{Num}\ \alpha \Rightarrow \textbf{Monoid}\ \varnothing\ (\Lambda x\,y. (x,y))\ \alpha\ \text{ where}\\ & id = const\ 0\\ & \otimes = uncurry\ (+) \end{align}$

$\begin{align} \text{instance} &\textbf{Monoid}\ \textbf{Id}\ (\Lambda f\,g\,\alpha. f\ (g\,\alpha))\ [\,]\ \text{ where}\\ & id\ (\textbf{Id}\ x) = [x]\\ & \otimes [xs] = xs \end{align}$

But this doesn’t work, since the type of id for our second (monadic) instance reduces to Id → [], which doesn’t type-check: that is, the kind of ( → ) is  ⋆  →  ⋆  →  ⋆ , but the kind of each of its operands in id is already ( ⋆  →  ⋆ ). What this means is that for monadic instances of Monoid, we need an arrow type constructor of kind ( ⋆  →  ⋆ ) → ( ⋆  →  ⋆ ) →  ⋆ . So we need to abstract over kind of arrow constructor:

$\begin{align} \text{class} &\textbf{Monoid}\ (\leadsto\;: k\to k\to\star)\ (id: k)\ (\times : k\to k\to \star)\ (m : k)\ \text{ where}\\ & id: id \leadsto m\\ & \otimes: m\times m \leadsto m \end{align}$

A normal monoid deals with function arrows and pairs:

$\begin{align} \text{instance} &\textbf{Num}\ \alpha \Rightarrow \textbf{Monoid}\ (\to)\ \varnothing\ (\Lambda x\,y. (x,y))\ \alpha\ \text{ where}\\ & id = const\ 0\\ & \otimes = uncurry\ (+) \end{align}$

A monadic monoid deals with natural transformations and composed functors:

$\begin{align} \text{instance} &\textbf{Monoid}\ (\Lambda f\,g\,\alpha. f\,\alpha\to g\,\alpha)\ \textbf{Id}\ (\Lambda f\,g\,\alpha. f\ (g\,\alpha))\ [\,]\ \text{ where}\\ & id\ (\textbf{Id}\ x) = [x]\\ & \otimes [xs] = xs \end{align}$

The Haskell Version

We’ll need to turn on a bunch of GHC extensions.

> {-# LANGUAGE PolyKinds #-}
> {-# LANGUAGE MultiParamTypeClasses #-}
> {-# LANGUAGE FlexibleInstances, FlexibleContexts #-}
> {-# LANGUAGE UndecidableInstances #-}
> {-# LANGUAGE FunctionalDependencies #-}
> {-# LANGUAGE RankNTypes #-}
> {-# LANGUAGE TypeOperators #-}
> {-# LANGUAGE DeriveFunctor #-}
> {-# LANGUAGE UnicodeSyntax #-}

> module GeneralizedMonoid where
> import Control.Monad (Monad(..))
> import Data.Monoid (Monoid(..))

First we define the type class Monoidy:

> class Monoidy (~>) comp id m | m (~>) → comp id where
>   munit :: id ~> m
>   mjoin :: m `comp` m ~> m

We use functional dependencies to help the typechecker understand that m and ~> uniquely determine comp (times) and id.

This kind of type class would not have been possible in previous versions of GHC; with the new kind system, however, we can abstract over kinds!² Now, let’s create types for the additive and multiplicative monoids over the natural numbers:

> newtype Sum a = Sum a deriving Show
> newtype Product a = Product a deriving Show
> instance Num a ⇒ Monoidy (→) (,) () (Sum a) where
>   munit _ = Sum 0
>   mjoin (Sum x, Sum y) = Sum $ x + y
> instance Num a ⇒ Monoidy (→) (,) () (Product a) where
>   munit _ = Product 1
>   mjoin (Product x, Product y) = Product $ x * y

It will be slightly more complicated to make a monadic instance with Monoidy. First, we need to define the identity functor, a type for natural transformations, and a type for functor composition:

> newtype Id α = Id { runId :: α } deriving Functor

A natural transformation (Λ f g α. (f α) → (g α)) may be encoded in Haskell as follows:

> newtype NT f g = NT { runNT :: ∀ α. f α → g α }

Functor composition (Λ f g α. f (g α)) is encoded as follows:

> newtype FC f g α = FC { runFC :: f (g α) }

Now, let us define some type T which should be a monad:

> newtype Wrapper a = Wrapper { runWrapper :: a } deriving (Show, Functor)
> instance Monoidy NT FC Id Wrapper where
>   munit = NT $ Wrapper . runId
>   mjoin = NT $ runWrapper . runFC

With these defined, we can use them as follows:

ghci> mjoin (munit (), Sum 2)
      Sum 2
ghci> mjoin (Product 2, Product 3)
      Product 6
ghci> runNT mjoin $ FC $ Wrapper (Wrapper "hello, world")
      Wrapper {runWrapper = "hello, world" }

We can even provide a special binary operator for the appropriate monoids as follows:

> (<+>) :: Monoidy (→) (,) () m ⇒ m → m → m
> (<+>) = curry mjoin

ghci> Sum 1 <+> Sum 2 <+> Sum 4
      Sum 7

Now, all the extra wrapping that Haskell requires for encoding this is rather cumbersome in actual use. So, we can give traditional Monad and Monoid instances for instances of Monoidy:

> instance Monoidy (→) (,) () m ⇒ Monoid m where
>   mempty = munit ()
>   mappend = curry mjoin

> instance (Functor m, Monoidy NT FC Id m) ⇒ Monad m where
>   return x = runNT munit $ Id x
>   x >>= f = runNT mjoin $ FC (f `fmap` x)

And so the following works:

ghci> mappend mempty (Sum 2)
      Sum 2
ghci> mappend (Product 2) (Product 3)
      Product 6
ghci> join $ Wrapper $ Wrapper "hello"
      Wrapper {runWrapper = "hello" }
ghci> Wrapper "hello, world" >>= return
      Wrapper {runWrapper = "hello, world" }

If you got this far…

I hope you enjoyed that! I can’t express enough my thanks to the people who came before me and helped me indirectly to refine my ideas and understanding of the relationship between monads and monoids. Additionally, a shout-out to the GHC team for adding kind polymorphism!

The latest versions of the Clang compiler extend the Objective-C language with related return types, which allow a limited form of covariance to be expressed. Methods with certain names (alloc, init, etc.) are inferred to return an object of the instance type for the receiver; other methods can participate in this covariance by using the instancetype keyword for the return type annotation.

Typically, this feature is used for convenience constructors which would previously have returned id. However, we can also use it to encode statically-typed collections without full-blown generics.¹

Decorating Types with Protocols

If Objective-C had parametric polymorphism (that is, the ability to abstract over types), then a simple typesafe collection would be trivial:

1
2
3
4

@protocol OrderedCollection[V]
- (V)at:(NSUInteger)index;
- (void)put:(V)object;
@end

With instancetype, we support a subset of parametric polymorphism: that is, we can abstract over one type (the type of an instance of the implementing class), and we are limited to referring to this type in method return types.² So, we can approximate something rather close, but slightly less safe and precise:

1
2
3
4

@protocol OrderedCollection
- (instancetype)at:(NSUInteger)index;
- (void)put:(id)object;
@end

Since we are limited to abstracting over the type of self, the static type of any such collection must actually be the type of its elements decorated by the <OrderedCollection> protocol. So, a collection of strings statically be understood to be a single string, decorated with collection methods:

1
2
3

NSString <OrderedCollection> *strings = ...;
[strings put:@"hello,"];
[strings put:@"world!"];

Higher Order Messaging

The fact that the static type of such a collection is the product of the type of its elements and a collection trait gives rise serendipitously to the applicability of higher-order-messaging, or HOM. For instance, what does it mean if you send NSString-messages to an object NSString <OrderedCollection>*? It makes sense to treat the collection as a Functor and map the message over its elements:

1
2
3
4
5

for (NSString *upperString in [strings.uppercaseString substringFromIndex:1])
  NSLog(@"%@", upperString);

// => ELLO,
// => ORLD!

An Implementation

We’ll implement covariant protocols <OrderedCollection, MapCollection>.

The collection interfaces

1
2
3
4
5
6
7
8
9

@protocol OrderedCollection <NSFastEnumeration>
- (instancetype)at:(NSUInteger)index;
- (void)put:(id)object;
@end

@protocol MapCollection <NSFastEnumeration>
- (instancetype)at:(id)key;
- (void)put:(id)object at:(id)key;
@end

Collection Proxies

We will use proxy objects to implement both the HOM and the checked collection accessors. First, we start with an abstract base CollectionProxy class, in terms of which proxies for both arrays and dictionaries will be expressed:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159

@interface CollectionProxy : NSObject
@property (strong) id target;
@property (assign) class elementClass;

- (id)initWithTarget:(id)target;

+ (Class)collectionClass;

// Subclasses will provide a technique for mapping an element in one
// collection to a new element in another.
- (void)appendMappedObject:(id)mapped fromObject:(id)original toBuffer:(id)buffer;

// Subclasses may wish to map over an object derivable from object
// given in fast enumeration. For instance, dictionaries map over
// values, rather than keys.
- (id)redirectIteration:(id)object;
@end

@implementation CollectionProxy
@synthesize target, elementClass;

- (id)initWithTarget:(id)aTarget {
  if ((self = [super init]))
    target = aTarget;

  return self;
}

- (id)init {
  return [self initWithTarget:[self.class.collectionClass new]];
}

- (NSMethodSignature *)methodSignatureForSelector:(SEL)sel {
  if ([self.class.collectionClass instancesRespondToSelector:sel])
    return [self.class.collectionClass instanceMethodSignatureForSelector:sel];

  return [self.elementClass instanceMethodSignatureForSelector:sel];
}

- (BOOL)respondsToSelector:(SEL)aSelector {
  return [super respondsToSelector:aSelector]
      || [target respondsToSelector:aSelector]
      || [self.elementClass instancesRespondToSelector:aSelector];
}

- (void)forwardInvocation:(NSInvocation *)invocation {
  // If the collection itself responds to this selector (like if
  // someone sent -count), we'll forward the message to it.
  if ([target respondsToSelector:invocation.selector])
    return [invocation invokeWithTarget:target];

  // If the invocation returns void, we still want to invoke it, but
  // we don't want to try to do anything with its results.
  BOOL returnsValue = strcmp("v", invocation.methodSignature.methodReturnType) != 0;
  id buffer = returnsValue ? [self.class.collectionClass new] : nil;

  for (id obj in target) {
    [invocation retainArguments];
    [invocation invokeWithTarget:[self redirectIteration:obj]];

    void *outPtr = NULL;
    if (returnsValue) {
      [invocation getReturnValue:&outPtr];

      // We marshall the return value of the invocation back into our space.
      id mapped;
      if ((mapped = objc_unretainedObject(outPtr)))
        [self appendMappedObject:mapped fromObject:obj toBuffer:buffer];
    }
  }

  if (returnsValue && [buffer count] > 0) {
    // Build up a new proxy of the same kind to return.
    CollectionProxy *proxy = [[self.class alloc] initWithTarget:buffer];

    // We marshall the proxy out of our space and set it as the return
    // value of our invocation.
    invocation.returnValue = &(const void *){
      objc_unretainedPointer(proxy)
    };
  }
}

// Default behavior

+ (Class)collectionClass { return nil; }
- (void)appendMappedObject:(id)mapped fromObject:(id)original toBuffer:(id)buffer {}
- (id)redirectIteration:(id)object { return object; }

@end

@interface OrderedCollectionProxy : CollectionProxy
@end

@interface MapCollectionProxy : CollectionProxy
@end


@implementation OrderedCollectionProxy

- (id)initWithTarget:(id)target {
  if ((self = [super initWithTarget:target]) && [target count])
    self.elementClass = [[target lastObject] class];

  return self;
}

+ (Class)collectionClass {
  return [NSMutableArray class];
}

- (void)appendMappedObject:(id)mapped fromObject:(id)original toBuffer:(id)buffer {
  [buffer addObject:mapped];
}

- (void)put:(id)object {
  assert([object isKindOfClass:self.elementClass]);
  [self.target addObject:object];
}

- (instancetype)at:(NSUInteger)index {
  return [self.target objectAtIndex:index];
}

@end


@implementation MapCollectionProxy

- (id)initWithTarget:(id)target {
  if ((self = [super initWithTarget:target]) && [target count])
    self.elementClass = [[target allValues].lastObject class];

  return self;
}


+ (Class)collectionClass {
  return [NSMutableDictionary class];
}

- (void)appendMappedObject:(id)mapped fromObject:(id)key toBuffer:(id)buffer {
  [buffer setObject:mapped forKey:key];
}

- (id)redirectIteration:(id)key {
  return [self.target objectForKey:key];
}

- (void)put:(id)object at:(id)key {
  assert([object isKindOfClass:self.elementClass]);
  [self.target setObject:object forKey:key];
}

- (instancetype)at:(id)key {
  return [self.target objectForKey:key];
}

@end

Collection Constructors

To construct a collection of some class, we send a message to that class with a covariant return type; unfortunately, we cannot decorate instancetype with any further protocols. So, ideally +orderedCollection would return instancetype <OrderedCollection>, but this is currently impossible; thus, you will have to provide the type decoration yourself.³

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

@interface NSObject (Collections)
+ (instancetype)orderedCollection;
+ (instancetype)mapCollection;
@end

@implementation NSObject (Collections)

+ (instancetype)orderedCollection {
  CollectionProxy *proxy = [OrderedCollectionProxy new];
  proxy.elementClass = self;
  return proxy
}

+ (instancetype)mapCollection {
  CollectionProxy *proxy = [MapCollectionProxy new];
  proxy.elementClass = self;
  return proxy;
}

@end

See it in action

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

NSURL <MapCollection> *sites = (id)[NSURL mapCollection];
[sites put:[NSURL URLWithString:@"http://www.jonmsterling.com/"]
        at:@"jon"];
[sites put:[NSURL URLWithString:@"http://www.reddit.com/"]
        at:@"reddit"];
[sites put:[NSURL URLWithString:@"git://github.com/jonsterling/Foam.git"]
        at:"foam_repo"];

NSURL *jonsSite = [sites at:@"jon"];
// => http://www.jonmsterling.com/

NSString <MapCollection> *schemes = (id)sites.scheme.uppercaseString;
/* => { jon: "HTTP://",
        reddit: "HTTP://",
        foam_repo: "GIT://" }
 */

Further Exercises

These HOMs do not correctly handle methods that return non-object types. It is definitely possible to write a more robust version that will box primitives appropriately, but not within the scope of this post. This will require further inspection of the method signature of the forwarded invocation.

In February, I wrote about using instancetype to get semi-typesafe collections in Objective-C. After an email conversation with Patrick Beard, I’d like to present another approach.

One sad consequence of protocols only being commonly used to encode delegation is that beginners frequently conflate protocols with delegation. Hence the proliferation of tutorials on how to “do delegates” in Objective-C; in fact, I had written one such tutorial a long time ago, and it became so popular that I deleted it, for it was feeding directly into this very conflation (which I deem damaging to learners).

In this article, I’ll be showing a more interesting use of protocols: typesafe collections.

Narrowing Static Type with Refinement Protocols

In a static-dynamic language like Objective-C, the static type of an object is distinct from its runtime type; in fact, because of mechanisms like forwarding, the runtime type of an object is really quite difficult to pin down (and may change over time)¹.

We can take advantage of this disparity by enforcing further restrictions on an object’s interface at compiletime, this eliminating some common sources of programmer error, as well as removing the need for downcasts in many cases.

A protocol for dictionaries of numbers

Take, for instance, the following protocols:

@protocol NSNumberDictionary <NSObject>
- (NSNumber *)objectForKey:(NSString *)key;
- (NSNumber *)objectForKeyedSubscript:(NSString *)key;
@end

@protocol NSNumberMutableDictionary <NSNumberDictionary>
- (void)setObject:(NSNumber *)number forKey:(NSString *)key;
- (void)setObject:(NSNumber *)number forKeyedSubscript:(NSString *)key;
@end

@interface NSDictionary (NSNumberDictionary) <NSNumberDictionary>
@end
@interface NSMutableDictionary (NSNumberMutableDictionary) <NSNumberMutableDictionary>
@end

Now, we can safely interact with a dictionary that is supposed to have only numbers as values:

id <NSNumberMutableDictionary> ages = [NSMutableDictionary new];
ages[@"jon"] = @19;
ages[@"dan"] = @"53"; // <--- Incompatible pointer types sending 'NSString *' to parameter of type 'NSNumber *'

// dot notation also works, because our types are fixed statically:
NSUInteger jonAge = ages[@"jon"].unsignedIntegerValue;

Incidentally, due to what would seem to be a bug in Clang, even though our <NSNumberDictionary> protocol does not include a signature for -setObject:forKeyedSubscript:, the following code compiles with no complaint:

// this compiles, but it shouldn't:
id <NSNumberDictionary> immutableDictionary = [NSDictionary new];
immutableDictionary[@"key"] = @45;

Until this is fixed, we can work around it by providing an impossible signature in our immutable protocol:

typedef struct {} MutationUnavailableForImmutableObject;
@protocol NSNumberDictionary <NSObject>
- (NSNumber *)objectForKey:(NSString *)key;
- (NSNumber *)objectForKeyedSubscript:(NSString *)key;
- (void)setObject:(MutationUnavailableForImmutableObject)object forKeyedSubscript:(NSString *)key;
@end

id <NSNumberDictionary> immutableDictionary = [NSDictionary new];
immutableDictionary[@"key"] = @45;
// ^-- Method object parameter type 'MutationUnavailableForImmutableObject' is not object type

Generalizing our technique with macros

So far, our approach has involved making new refinement protocols for every possible element type. This is obviously untenable, but we can make things easier by encoding generic protocols as macros:

First, let’s make a macro that handles the creation of any protocol and a dummy adopting category for a class:

#define GenericProtocol(T,E,Name,...)\
@protocol E##Name <NSObject>\
__VA_ARGS__\
@end\
@interface T (E##Name) <E##Name>\
@end

We’ll also need a macro for a mutable variant that depends on the immutable protocol:

#define GenericMutableProtocol(T,E,Name,...)\
@protocol E##Mutable##Name <E##Name>\
__VA_ARGS__\
@end\
@interface T (E##Mutable##Name) <E##Mutable##Name>\
@end

Now, if the immutable protocol includes a -mutableCopy method, it will have to return an object of the mutable variant. So, we need to provide forward declarations for the protocols:

#define ForwardDeclareMutable(E,Name)\
protocol E##Mutable##Name

You probably noticed that we didn’t include the @ before protocol in this macro; this is a little trick that will allow us to have our macros begin with the @-sign, just like real Objective-C directives. It’s not necessary, but it’s a nice little sleight of hand. And now, we can provide our generic dictionary macro:

#define DictProtocol(E) ForwardDeclareMutable(E,Dictionary)\
GenericProtocol(NSDictionary, E, Dictionary,\
  - (id <E##Dictionary>)copy;\
  - (id <E##Mutable##Dictionary>)mutableCopy;\
  - (E *)objectForKey:(NSString *)key;\
  - (E *)objectForKeyedSubscript:(NSString *)key;\
  - (void)setObject:(MutationUnavailableForImmutableObject)object forKeyedSubscript:(NSString *)key;\
)\
GenericMutableProtocol(NSMutableDictionary, E, Dictionary,\
  - (void)setObject:(E *)object forKey:(NSString *)key;\
  - (void)setObject:(E *)object forKeyedSubscript:(NSString *)key;\
  - (void)addEntriesFromDictionary:(id <E##Dictionary>)otherDictionary;\
  - (void)setDictionary:(id <E##Dictionary>)otherDictionary;
)

Finally, we can instantiate typed dictionary protocols for various object types:²

@DictProtocol(NSNumber);
@DictProtocol(NSString);
@DictProtocol(NSData);
@DictProtocol(NSArray);

The downside to our approach

Ambiguity: multiple signatures for a method

The most glaring problem with this approach is that we are injecting multiple signatures for a single method into a single class (via our categories). So, the result is that it becomes impossible to interact with a non-pimped collection; the following code may fail:

NSMutableDictionary *plainDict = [NSMutableDictionary new];
plainDict[@"key"] = @"a string";
// <-- Compiler was expecting some other random type that we have instantiated,
//     like NSData or something. Oops.

So anywhere these refinement protocols and the associated categories are in scope, we are obliged to use them. For many people, that is too great a demand.

We can instead just remove our categories can keep these method signatures scoped in their protocols. But then we have to do an unsafe downcast to id whenever we wish to instantiate a new typed dictionary. That’s rather close to beating the point.

Lastly, literals can never be typesafe, since the signature of +arrayWithObjects:count: and friends is required to take a parameter no more precise than id[] for literal creation (if you don’t believe me, see Sema::BuildObjCArrayLiteral in SemaExprObjC.cpp). And even more important, the literal expression compiler of course does not abstract over the intended type of its result! So even if it were possible to have one of these methods with a more precise signature, the compiler would still have no way to disambiguate which method signature to follow in any given instance. This may be fixable, but would likely require a not insignificant amount of compiler rejiggering.

Concluding Remarks

It’s a rather nice idea for getting around Objective-C’s lack of type safety, and I thank Patrick for getting me to think about it a little more. It’s not perfect, however, and its necessary deficiencies will likely prevent its use in shipping code for now. If anyone has any ideas on how to improve this and make it work better, I’m all ears!

Funny how we like to talk about total functions. As if there’s any other kind of function.

This was my somewhat flippant remark this morning, which incited a conversation about the nature of functions and partial functions, leading me to learn a few things.

But aren’t partial functions another kind of function? This was a response to my remark, and I think it deserves to be addressed.

The way I see it, a partial function is somewhat less than a function, because it doesn’t fulfill all of the requirements of being a function: namely that it maps every element of its domain X to an element of its codomain Y:

$\begin{align} f&: X \mapsto Y\\ p&: X' \mapsto Y\ \text{where}\ X' \subseteq X \end{align}$

But another way to look at it, which I hadn’t thought of previously, was that partial functions are a generalization of functions, and so they are more than a function: they broaden the expectations to include things things that don’t conform to the definition of “function” or “total function”.

Does that mean that a partial function is actually more than a function rather than less? No, I don’t believe that to be the case. For instance, rectangles generalize squares to include right-angled quadrilaterals which are irregular; and so the requirements of rectangle are somewhat less than the requirements of square.

We’re talking about the size of their requirements, not the number of conforming entities. In fact, these two things are basically inverse to each other: as the specificity of requirements increases, the field of conforming entities narrows.

So in terms of requirements, a partial function is indeed less than a function. To avoid confusion, the following terminology might help: partiality is a weaker contract than totality.

Because Haskell doesn’t have real ∏ -types, we can’t bring those invariants into our program specifications in the same way a dependently-typed language could. But with GHC 7.4’s new -XDataKinds extension, many data types are automatically promoted into the kind-level; this means that we can maintain a static-dynamic phase distinction at the same time as having data structures mirrored into the kind level. Combined with phantom-types, this is enough to start encoding interesting invariants into the type system. But, reusing statically verified code for dynamic values can be problematic.

Let’s look back at our length-indexed vectors to see the problem first-hand:

> {-# LANGUAGE GADTs #-}
> {-# LANGUAGE DataKinds #-}
> {-# LANGUAGE KindSignatures #-}
> {-# LANGUAGE ExistentialQuantification #-}
> {-# LANGUAGE StandaloneDeriving #-}
> {-# LANGUAGE TypeFamilies #-}

> module PhasedConstraints where
> import Control.Applicative ((<$>))

> data Nat = Z | S Nat
> infixr :>
> data Vect :: * -> Nat -> * where
>   VNil :: Vect a Z
>   (:>) :: a -> Vect a n -> Vect a (S n)
> deriving instance Show a => Show (Vect a n)

It’s trivial to write safe head and tail functions now:

vhead :: Vect a (S n) -> a
vhead (x :> xs) = x

vtail :: Vect a (S n) -> Vect a n
vtail (x :> xs) = xs

But what if we don’t statically know the size of our vector? For instance, if we are converting a plain old list to a vector, or if we are parsing some file. We’d presumably box up the vector and existentially quantify its length:

> data EVect :: * -> * where
>   EVect :: Vect a n -> EVect a
> deriving instance Show a => Show (EVect a)

Now we can marshall [α] into ∀ (α: Set). ∃ (n: N). aⁿ:

> fromList :: [a] -> EVect a
> fromList [] = EVect VNil
> fromList (x:xs) =
>   case fromList xs of
>     EVect v -> EVect $ x :> v

But now, we’re in a bit of a pickle, since we cannot reuse our vhead and vtail. So, we can just write new ones that target Maybe:

evhead :: EVect a -> Maybe a
evhead (EVect VNil)     = Nothing
evhead (EVect (a :> b)) = Just a

evtail :: EVect a -> Maybe (EVect a)
evtail (EVect VNil)     = Nothing
evtail (EVect (a :> b)) = Just (EVect b)

But this is certainly less-than-desirable. We haven’t reused any of our code. Imagine how unfortunate this would be for a function that is more complicated than head or tail… What we actually need is a way to marshall a function with static guarantees to a function with dynamic guarantees without rewriting everything, and without case analysis.

Types as Propositions

What if instead of restricting the type of the input of vhead, we just required a proof that it was a nonempty vector? Let’s try that. Under the Curry-Howard correspondance, types are propositions, and values are proofs. So, we can create a type that represents the proposition greater-than-zero for natural numbers:

> data NotZero :: Nat -> * where
>   NotZero :: NotZero (S n)
> deriving instance Show (NotZero n)

Basically, excluding bottom, NotZero n does not have any inhabitants of type NotZero Z. So, forall natural numbers n, any value NotZero n is a proof that n is not zero. And we can just take this as a parameter in our new version of vhead:

> vhead :: Vect a n -> NotZero n -> a
> vhead (x :> xs) NotZero = x

To use vhead, just include the proof in the parameters:

exampleVector = "hello" :> "world" :> VNil
hello = vhead exampleVector NotZero
-- typeError = vhead VNil NotZero

It’s a bit more complicated for vtail, since the length of its input must be universally quantified for it to be able to be applied to a vector with existentially quantified length; that is, behavior must not depend on the value of the index, since the index will just be a skolem type variable in the unpacked existential. So, we need to do subtraction in the right-hand side of the arrow, rather than structural recursion on the left side. To do this, we can use a type family:

> type family Prev (n :: Nat) :: Nat
> type instance Prev (S n) = n

> vtail :: Vect a n -> NotZero n -> Vect a (Prev n)
> vtail (x :> xs) NotZero = xs

Now, in order to make this work for vectors of unknown length, we need a function that can generate a NotZero proof for all vectors if applicable:

> notEmpty :: Vect a n -> Maybe (NotZero n)
> notEmpty VNil = Nothing
> notEmpty (x :> xs) = Just NotZero

And now, implementing evhead and evtail in terms of the originals is trivial, thanks to currying:

> evhead :: EVect a -> Maybe a
> evhead (EVect v) = vhead v <$> notEmpty v

> evtail :: EVect a -> Maybe (EVect a)
> evtail (EVect v) = EVect . vtail v <$> notEmpty v

Gloriously, all the pattern matching and so forth is factored out into the proof generator. This is especially helpful if you have a whole family of functions that you want to be available to both your statically indexed values, and those whose indices are only known dynamically.

Taking a breath.

The reason we even bothered to do this is that there are more instances of statically verifiable computation in our programs than we like to think. For instance, any time we use a literal form for a data structure, rather than building it up inductively from IO, we are doing something that might benefit from static verification.

But in the popular literature on dependent types (and faking-dependent-types-with-GADTs), there’s quite a bit of focus on building machinery to facilitate this static verification, but not a lot of details on how to make that machinery useful for dynamic data. By factoring constraints into explicit proofs, we can allow our constraints to be checked in different program phases (compilation or execution), according to the requirements of our data (static or dynamic). In a sense, we get to have our cake, and eat it too.

Before we begin, I’d like to further address the question of whether we even need to use explicit proof terms, as it would seem that we could simply use type classes to express our constraints. Let’s try that with a mirroring vector (an collection of an indexed type, where its value is mirrored in both the value and type levels). First, the usual boilerplate:

> {-# LANGUAGE GADTs, KindSignatures #-}
> {-# LANGUAGE DataKinds, PolyKinds #-}
> {-# LANGUAGE FlexibleInstances #-}
> {-# LANGUAGE FlexibleContexts #-}
> {-# LANGUAGE TypeOperators #-}
> {-# LANGUAGE TypeFamilies #-}
> {-# LANGUAGE MultiParamTypeClasses #-}
> {-# LANGUAGE OverlappingInstances #-}

> import Control.Applicative

For some indexed type f i, there is a vector parameterized by a type-level list of i, holding a linked list of values f i.

> infixr :<
> data Vect f is where
>   VNil :: Vect f '[]
>   (:<) :: f i -> Vect f is-> Vect f (i ': is)

An example indexed type for the vector might be a natural number GADT:

> data Nat = Z | S Nat
> data DNat (n :: Nat) where
>   DZ :: DNat Z
>   DS :: DNat n -> DNat (S n)

> natToNum :: Num a => DNat n -> a
> natToNum DZ = 0
> natToNum (DS n) = 1 + natToNum n

> instance Show (DNat n) where
>   show = show . natToNum

We wish to have a function to get the index of an item that’s contained in the vector. For that to be safe, we need to be able to prove that the item is even contained in the vector.

An attempt without explicit witnesses

So, we’ll first try just using a type class. Since the values are guaranteed to be mirrored by the type-list, this is a reasonable way to do it:

class Elem' i is
instance Elem' i (i ': is)
instance Elem' i is => Elem' i (j ': is)

But you’ll quickly find that writing a function which uses this constraint is not a simple proposition. In fact, it would appear to be impossible for more than one reason. If we wish to use type classes in this way, we shall actually have to write an IndexOf type class:

class IndexOf i is where
  indexOf :: Num a => Vect f is -> f i -> a
instance IndexOf i (i ': is) where
  indexOf (i :< is) i' = 0
instance IndexOf i is => IndexOf i (j ': is) where
  indexOf (j :< is) i = 1 + indexOf is i

And that class will do what we expect, but it complects constraint with behavior. This is a “bad” thing, since there may be other functions that require a similar constraint but quite different behavior. That smells of poor factoring. And so we must return to our explicit proof witness strategy.

An attempt with explicit witnesses

A witness that a value is an item of our mirrored vector is an instance of an inductive family. The base case is that the element lies at the beginning; if we have a proof that it lies somewhere in the vector’s tail, we also have a proof that the it is an element of the vector as a whole:

> data Elem a as where
>   Here :: Elem x (x ': xs)
>   There :: Elem x xs -> Elem x (y ': xs)

And so we implement indexOf by recursing through both the values and the layers of proofs!

> indexOf :: Num a => Vect f is -> f i -> Elem i is -> a
> indexOf (x :< xs) x' Here = 0
> indexOf (y :< xs) x (There p) = 1 + indexOf xs x p

But, of course, this is absolutely useless at a glance, since in order to even use the function, the programmer has to type a chain of proofs isomorphic to the Peano encoding of the item’s index anyway!

> testVect :: Vect DNat [Z, S (S Z), S Z]
> testVect = DZ :< (DS (DS DZ)) :< (DS DZ) :< VNil
> noBueno = indexOf testVect (DS (DS DZ)) (There Here) -- 1

So, this is a total non-starter unless we can generate the proof term. Since only one term is needed to prove a proposition, we can make a very simple type class for proof inference:

> class Infer p where
>   infer :: p

And we can directly mirror the Elem family (but in the opposite direction):

> instance Infer (Elem x (x ': xs)) where
>   infer = Here
> instance Infer (Elem x xs) => Infer (Elem x (y ': xs)) where
>   infer = There infer

It’s trivial to write and use a variant of indexOf which uses our new proof inference class:

> indexOf' xs x = indexOf xs x infer
> muchoBueno = testVect `indexOf'` (DS (DS DZ)) -- 1

Another example: safe vector access

To access a vector at a given index, we need to make sure it’s within bounds. So, we first provide a way to get the length of a type-list:

> type family Length xs :: Nat
> type instance Length '[] = Z
> type instance Length (x ': xs) = S (Length xs)

We also need to provide a way to get an element from a type list using an index:

> type family At xs n :: Nat
> type instance At (x ': xs) Z = x
> type instance At (x ': xs) (S n) = At xs n

And now we need a type of less-than proofs:

> data LT (l :: Nat) (r :: Nat) where
>   ZLT :: LT Z (S n)
>   SLT :: LT n m -> LT (S n) (S m)

The way we go about at is much the same as in the previous example, just a tiny bit more complicated in the types.

> at :: Vect f is -> DNat n -> LT n (Length is) -> f (At is n)
> at (x :< xs) DZ ZLT = x
> at (y :< xs) (DS n) (SLT lt) = at xs n lt

> instance Infer (LT Z (S n)) where
>   infer = ZLT

> instance Infer (LT n m) => Infer (LT (S n) (S m)) where
>   infer = SLT infer

> v @. i = at v i infer

> hailMary = testVect @. (DS DZ) -- 2

Inferring dynamic proofs

Dynamic proof inference is the same as static proof inference, except that it may fail:

> class DynamicInfer p where
>   inferDynamic :: Maybe p

We have to go through this little dance for each proof which we want to make available dynamically. The routine is repetitive enough that one could conceivably use Template Haskell to factor it out, though I’d certainly be pleased to learn if there was a more clean and succinct way of doing it.

> instance DynamicInfer (Elem x (x ': xs)) where
>   inferDynamic = Just infer
> instance DynamicInfer (Elem x xs) => DynamicInfer (Elem x (y ': xs)) where
>   inferDynamic = There <$> inferDynamic
> instance DynamicInfer (Elem x ys) where
>   inferDynamic = Nothing

> instance DynamicInfer (LT Z (S n)) where
>   inferDynamic = Just infer
> instance DynamicInfer (LT n m) => DynamicInfer (LT (S n) (S m)) where
>   inferDynamic = SLT <$> inferDynamic
> instance DynamicInfer (LT n m) where
>   inferDynamic = Nothing

And now it is trivial to make dynamic versions of our functions:

> dynamicIndexOf :: Num a => Vect f is -> f i -> Maybe a
> dynamicIndexOf xs x = indexOf xs x <$> inferDynamic

> dynamicAt :: DynamicInfer (LT n (Length is)) => Vect f is -> DNat n -> Maybe (f (At is n))
> dynamicAt xs i = at xs i <$> inferDynamic

∏  generalizes arrows, ∑  generalizes products

Anyone who took elementary mathematics is probably aware that ∏  is the mathematical symbol for a product of a sequence; you’ve probably seen something like this: $\begin{align} \prod_{i\in\mathbb{N}} f(i) \end{align}$, the product of f(i) over the set of all natural numbers N.

The word “product” gets us mistakenly thinking that a ∏ -type should be a pair or something, like (,) in Haskell. Consider the following function type for making a vector of ’!’-characters of a given length in an Agda-like language with dependent types:

replicate : (n:ℕ) → Vect n Char -- syntactic sugar
replicate : Π(n:ℕ). Vect n Char -- translated into ∏-notation
replicate 0     = []
replicate (n+1) = '!' :: (replicate n)

Most dependently-typed languages offer syntactic sugar to allow including terms inside the function-arrow syntax. In fact, we actually can see that for some type P which does not depend on x, Π(x:T).P is exactly equivalent to the plain function type T → P. So how is this really a product?

Though this be madness, yet there is method in’t! Let’s see what happens when we restrict our ∏ -operator to have the second element not depend on the first.

Let’s look at a numerical example:

$\begin{align} f_x &= C\\ \prod_{i=0}^n f_i &= f_0 \times f_1 \times f_2 \times \cdots \times f_n\\ &= C^n \end{align}$

If f is constant over its input, then the multiplication can be collapsed into exponential notation. Now, the above example can be understood with an elementary understanding of grade-school numerical algebra; we can generalize it to hold for type algebra. But remember that an exponential type β^α is just a function type α → β! One way to think of it is to say that it maps every α into β-space.

Another way to think of it is to say that the codomain of a function is modelled by product of all the outputs of that function corresponding to the domain. For instance, consider the set B and some function name that maps bovines to strings:

$\begin{align} \textbf{B} &= \{ \text{Bessie}, \text{Brownie}, \text{Macy} \}\\ \textbf{name} &\in \prod_{b\in\textbf{B}}.\ \textbf{String}\\ &\approx \textbf{String}^\textbf{B}\\ &\approx \textbf{B} \to \textbf{String} \end{align}$

If we’d wanted to specify a function that mapped each bovine to its name paired with that specific bovine, we’d need to use a dependent type.

And so a ∏ -type is the (cartesian) product of all elements of its second component corresponding to its first component. In the case that the former is not dependent on the latter, this is a (cartesian) power: this is the space that functions of the second-order lambda calculus inhabit.

It’s much the same with ∑ -types. Let’s first take a numerical example:

$\begin{align} f_x &= C\\ \sum_{i=0}^n f_i &= f_0 + f_1 + f_2 + \cdots + f_n\\ &= C \times n \end{align}$

And so the sum of all the outputs, when the output set doesn’t depend on the input value, is just a product. Let’s look again at our bovine type to see how we can get pairs from this:

$\begin{align} \textbf{name} &\in \sum_{b\in\textbf{B}}.\ \textbf{String}\\ &\approx \textbf{String} \times \textbf{B}\\ \end{align}$

So, in this special non-dependent case, a ∑ -type is just a cartesian product (of bovines and strings): it specifies all possible pairs of bovines and string.

Realizing ∏  and ∑  in Agda

I find that nothing helps me understand a concept better than a concrete example in a language I understand. I’ll be using Agda today, but the same task could have been done in most other dependent-typed languages, including Idris.

module SigmaPi where

-- We use (dependent) records rather than plain-old data declarations
-- because these conveniently provide accessors; an accessor for a
-- Π-type corresponds to function application.
record Π (α : Set) (β : α → Set) : Set where
  constructor Λ
  field _$_ : ((x : α) → β x)

record Σ (α : Set) (β : α → Set) : Set where
  constructor _,_
  field
    fst : α
    snd : β fst

-- A special case of Π: the function arrow.
_~>_ : Set → Set → Set
_~>_ α β = Π α (λ _ → β)

-- A special case of Σ: the cartesian product.
_×_ : Set → Set → Set
_×_ α β = Σ α (λ _ → β)

Now, we can test them to see how they work:

module Tests where
  open import Data.Char
  open import Relation.Binary.Core

  open Π
  open Σ

  data Bovine : Set where
    Bessie  : Bovine
    Brownie : Bovine
    Macy    : Bovine

  pair : ℕ × Bovine
  pair = 43 , Macy

  suc' : ℕ ~> ℕ
  suc' = Λ suc

  -- We can prove trivial equalities to test:
  Σ-fst-test : fst pair ≡ 43
  Σ-fst-test = refl

  Σ-snd-test : snd pair ≡ Macy
  Σ-snd-test = refl

  Π-application-test : suc' $ 2 ≡ 3
  Π-application-test = refl

Coming up next: Universe Polymorphism

You may be wondering why I haven’t shown how to encode Haskell-style existentials; the problem is that they are actually impossible under the implementation I have given above. In the above implementation, the first part of the ∑  is a term of a type, but in order to forget (for instance) the type of a list’s elements, we’d need that first part to be a term of a kind. This calls for universe polymorphism, where the same code can be parameterized over universe levels; this will allow us to easily introduce Haskell-style existential types.

What is universe polymorphism? In our theory, values inhabit types, types inhabit kinds, and so forth (it’s larger sorts all the way up!) This stratification wraps up the idea that a proposition about a set of terms is their type; and so, if it’s possible to have a proposition about types, then that means they must have kinds; and if we can make propositions about kinds, then they must inhabit terms of some larger space, and so forth. It’s often useful to make a proposition that applies to multiple universes; this is what allows us to, for instance, use the same specification for encoding a list of values and a list of types.

Approaches to Universe Levels

The first approach to universe levels is just to ignore them altogether:

$\begin{align} \tau \in \textbf{Set} \in \textbf{Set} \in \textbf{Set} \in \textbf{Set}\cdots \tag{Dragons!} \end{align}$

This is unfortunate, and will allow us to prove any proposition, even if it is false. Agda provides this feature with its --type-in-type option; even though it would “solve” our problem, it is clearly a nonstarter.

The default approach in Agda is to universe polymorphism, where you parameterize Set with a level index, generating the hierarchy we know and love:

$\begin{align} \tau \in \textbf{Set}_0 \in \textbf{Set}_1 \in \textbf{Set}_2\cdots \tag{Stratification} \end{align}$.

The last approach, which is adopted by Idris, is Cumulativity.¹ Cumulativity adds a typing rule that says that terms in one level are also terms in higher levels:²

$\begin{align} \frac{\Gamma \vdash \tau \in \text{Set}_\ell} {\Gamma \vdash \tau \in \text{Set}_{\ell+1}} \tag{Cumulativity Rule} \end{align}$

Since we’re working in Agda, we will be using the explicit level-parameterization approach.

Adding Universe Polymorphism to ∏  and ∑ 

Without further delay, let’s rewrite yesterday’s code using universe polymorphism:

module SigmaPi where
  open import Level using (_⊔_)

  -- We specify the universe levels as implicit parameters to the type
  -- constructor. Then, we parameterize instances of `Set` with them.

  -- Our parameters may live in different universes, so the resulting
  -- type needs to live in the smallest universe that can hold both.
  -- The _⊔_ operator selects the maximum level of its arguments.
  record Π {l m} (α : Set l) (β : α → Set m) : Set (l ⊔ m) where
    constructor Λ
    field _$_ : ((x : α) → β x)
  open Π public

  record Σ {l m} (α : Set l) (β : α → Set m) : Set (l ⊔ m) where
    constructor _,_
    field
      fst : α
      snd : β fst
  open Σ public

  -- Not much change is needed to make our special cases work in the
  -- new system.
  _~>_ : ∀ {ℓ} → Set ℓ → Set ℓ → Set ℓ
  _~>_ α β = Π α (λ _ → β)

  _×_ : ∀ {ℓ} → Set ℓ → Set ℓ → Set ℓ
  _×_ α β = Σ α (λ _ → β)

Now, we should be able to existentially abstract out both types and values (previously, we could only abstract out values). Let’s build up some tackle:

  -- `exists` "forgets" a parameter of its argument; so, `exists P`
  -- would represent translate to `∃ α. P(α)` in logic.
  exists : ∀ {l m} {α : Set l} → (α → Set m) → Set (l ⊔ m)
  exists = Σ _

  -- We can define some syntactic sugar to get a cleaner, more familiar
  -- abstraction, which allows us to write `∃ α ⇒ P α ℕ` rather than
  -- the more verbose `exists (λ α → P α ℕ)`.
  syntax exists (λ α → P) = ∃ α ⇒ P

  -- Remember, an existential is just a pair containing a value on the
  -- left and a predicate that it satisfies on the right. To simplify
  -- introduction, we can create a little function `∃|` that will infer
  -- the first parameter (such as the length of a vector, or some type
  -- parameter).
  ∃| : ∀ {l m} {α : Set l} {β : α → Set m} {x} → β x → exists β
  ∃| x = _ , x

Hard work pays off: an example use

module Examples where
  open import SigmaPi
  open import Data.Nat

  data Bovine : Set where
    Bessie  : Bovine
    Brownie : Bovine
    Macy    : Bovine

  -- First, let's define a dependent vector type, indexed by its length.
  data Vector {ℓ} (α : Set ℓ) : ℕ → Set ℓ where
    []  : Vector α 0
    _∷_ : {n : ℕ} → α → Vector α n → Vector α (n + 1)
  infixr 5 _∷_

  all-bovines : Vector Bovine 3
  all-bovines = Bessie ∷ Brownie ∷ Macy ∷ []

  -- We can make a vector's length abstract (where the length is a value
  -- rather than a type):
  ∃-value-ex : ∃ n ⇒ Vector Bovine n
  ∃-value-ex = ∃| all-bovines

  -- We can now also make the type of a vector's elements abstract:
  ∃-type-ex : ∃ α ⇒ Vector α 3
  ∃-type-ex = ∃| all-bovines

Basics: The Sadly Typed Lambda Calculus

NL-semantics in the Montague tradition is typically done within a simply-typed lambda calculus, combined with some fast-and-loose subset-predicate stuff. I’ll try to avoid the nasty bits and just show you the context you need in order to understand what we’re doing. Let’s draw out the grammar and typing rules:

$\begin{align} \text{types} &::= e,\ t,\ \langle \text{type}, \text{type} \rangle \tag{Grammar}\\ \text{connectives} &::= \forall,\ \exists,\ \land,\ \lor,\ \lnot\\ \text{operators} &::= \lambda,\ \iota \end{align}$

e is the type of entities, and t is the type of propositions; ⟨e, t⟩ is a function from entities to propositions. Function types are written thus in angle-brackets as comma-separated lists of types, with the comma associating to the right. λ is the primative abstraction operator, and ι is the primitive singleton-inference operator.

In extensional semantics, t is just a truth value; in an intensional theory (which would seem to be necessary for reasons including the existence of hypotheticals and mood in language), t can be thought of as the set of all worlds in which some proposition holds true.

Typing rules are pretty straight-forward, given a context of type-assumptions Γ  (basically a list of values and their types).

$\begin{align} \frac{\Gamma, x:\sigma \vdash M:\tau} {\Gamma \vdash \lambda x.M : \langle\sigma,\tau\rangle} \tag{T-abstraction} \end{align}$

For some x: σ and M: τ (where the body of M may contain x), the lambda abstraction λx. M is a function of type ⟨σ, τ⟩.

$\begin{align} \frac{\Gamma, f : \langle\sigma,\tau\rangle \vdash x : \sigma} {\Gamma \vdash f(x) : \tau} \tag{T-application} \end{align}$

The application of a function f: ⟨σ, τ⟩ on a value x: σ is f(x): τ.

$\begin{align} \frac{\Gamma, x:e \vdash P : \langle e,t\rangle} {\Gamma\vdash \iota x.P(x) : e} \tag{T-inference} \end{align}$

For a predicate P: ⟨e, t⟩ which is satisfied by only one entity, the inference ιx. P(x) is that entity.

So under this framework, common nouns, adjectives and intransitive verbs are of type ⟨e, t⟩, whereas individuals (like “Tucker” and 42) are of type e. The ι-operator is used to map these ⟨e, t⟩ predicates to the contextually relevant value; if there are multiple (or zero) values in context that satisfy P, the derivation of ιx. P(x) will crash. So, the following are logical representations of words and phrases in this framework:

$\begin{align} ⟦\text{dog}⟧ &= \lambda x.\ \text{‘}x \text{ is a dog’} &&: \langle e,t\rangle\\ ⟦\text{the}⟧ &= \lambda P. \iota x. P(x) &&: \langle\langle e,t\rangle,e\rangle\\ ⟦\text{the}⟧(⟦\text{dog}⟧) &= \iota x.\ ⟦\text{dog}⟧(x)&&: e\\ ⟦\text{love}⟧ &= \lambda x. \lambda y.\ \text{‘}y \text{ loves } x\text{’} &&: \langle e,e,t\rangle \end{align}$

And so forth. In this representation, note that we define primitive predicates using an existing token in the metalanguage (in this case, English); it could have Greek or Latin.

Semantics in a Modern TT: Shifted Up a Level

In modern type theory, we have to sort of rejigger things a bit. The new world order is that simple nouns (formerly ⟨e, t⟩) are actually just types; so, rather than saying ⟦dog⟧(x), we now say x: ⟦dog⟧. We’ve actually hoisted most of our machinery into the type-level; under the Curry-Howard Correspondence, types are propositions, and terms are proofs of those propositions.

In our intensional interpretation of natural language semantics, then, different proofs will exist in different worlds; so, in all worlds, there is a proposition P, but it will be provable in only some subset of worlds. So, to interpret the truth-value of a P in some world, we are really trying to see if there exists a term of type P in that world. In a later post, I’ll talk about ways that we can express the concept of multiple worlds in the new framework.

Actual predicates are types indexed by values (so-called ∏ -types); values of a predicate type are proofs that the saturated predicate (proposition) holds. Modification of predicates (as in “heavy book”) is done using ∑ -types.²

To avoid getting mired in words, we can very simply encode this in Agda, a dependently-typed programming language with a few features that will prove very useful to us.

Agda: Let’s Formalize Our Semantics

Today, we’ll only show how to represent what we have currently demonstrated for the Montague-style theory. For those of you who don’t have much programming experience (let alone experience with Agda), I’ll try to leave helpful comments as we go. Let’s get started!

module Semantics where

We have a type for cats; in this context, there is only one cat. We’ll be using ⟦double-brackets⟧ for values which are referring to a word or phrase.

  data ⟦cat⟧ : Set where
    ⟦Emma⟧ : ⟦cat⟧

Our first order of business is to show how we can derive “the”.

First, we need to define propositional equality. Agda’s standard library actually has this built-in, but we’ll define it for ourselves so that we can see how it works.

  data _≡_ {A : Set} : A → A → Set where
    refl : {x : A} → x ≡ x

The ι operator can be seen as a proposition that for some proposition P, there is one-and-only-one proof (or, in other words, only one term inhabits type P).

A proof that a set P is singleton would consist of the single proof x, and a proof that all proofs of P are equal to x; that’s a pair, in which the second item (a function from a value to a proof that it is unique in some set P) is dependent upon the first item, which is the value which we’re trying to prove is the only inhabitant of P. This is a perfect use for a ∑ -type! Let’s define what that is:

  record ∑ (A : Set) (B : A → Set) : Set1 where
    constructor _,_
    field
      fst : A
      snd : B fst

We can define some syntactic sugar to make this a little easier to use:

  syntax ∑ A (λ x → B) = ∑[ x ∶ A ] B

And so, a singleton-proof is just a specific instantiation of ∑ :

  Singleton : Set → Set1
  Singleton P =  ∑[ x ∶ P ] (∀ y → y ≡ x)

“For some proof x of P, every proof y of P is equal to x.” In other words, x is the only proof of P.

Using the _,_ constructor from ∑ , we can make a proof that ⟦cat⟧ is a singleton set:

  cat-singleton : Singleton ⟦cat⟧
  cat-singleton = ⟦Emma⟧ , λ { ⟦Emma⟧ → refl }

We now have enough machinery to define the ι operator. Because we want to infer the proof that P is a singleton, we place that parameter in double-curly-braces; this is called an “instance argument” in Agda. If we did not do this, we would have to provide a proof that P is a singleton with every use of ι.

  ι : (P : Set) → {{proof : Singleton P}} → P
  ι _ {{x , _}} = x

It turns out that ⟦the⟧ is actually the exact same thing as ι!

  ⟦the⟧ : (P : Set) → {{proof : Singleton P}} → P
  ⟦the⟧ = ι

And now, to let all our hard work pay off, we can show that ⟦the⟧ really does work as we had hoped!

  ⟦the-cat⟧ : ⟦cat⟧
  ⟦the-cat⟧ = ⟦the⟧ ⟦cat⟧

If ⟦cat⟧ had been inhabited by more values, the program would have failed to typecheck (since it would have been impossible to construct a proof that ⟦cat⟧ is a singleton).

Next steps

Some things that still need to be discussed in a future post:

1. How can we unify our new view of semantics with the possible-worlds interpretation? How can we assert a “world-signature” (that says what kind of types and propositions we have), but allow the specific available theorems to differ from world-to-world?

2. How can we coerce a function of a more general type to a more specific type? For instance, “eat” might be represented by a type: ⟦animal⟧ → ⟦food⟧ → Set, but it should be possible to treat it as a function ⟦cat⟧ → ⟦tuna⟧ → Set. (For more on this, see Luo’s paper in the notes.)

Let’s see what’s necessary to fake dependent types with singletons in today’s GHC.

First, the usual boilerplate:

> {-# LANGUAGE NoMonomorphismRestriction #-}
> {-# LANGUAGE ScopedTypeVariables #-}
> {-# LANGUAGE PolyKinds, DataKinds #-}
> {-# LANGUAGE TypeOperators #-}
> {-# LANGUAGE TypeFamilies, MultiParamTypeClasses #-}
> {-# LANGUAGE UndecidableInstances, IncoherentInstances #-}
> {-# LANGUAGE FlexibleContexts, FlexibleInstances #-}
> {-# LANGUAGE ViewPatterns, UnicodeSyntax #-}
> {-# LANGUAGE RankNTypes, GADTs #-}

> module FakingIt where

> import Prelude hiding (lookup)
> import GHC.TypeLits

Now, in order to simulate dependent types, we need to allow data to exist in three forms:

1. Terms under types (we get this for free when we define data types).

2. Terms under kinds (we also get this for free when -XDataKinds is turned on).

3. Values that introduce indexed types (we must manually create or generate a GADT encoding of singleton sets). This is a sort of glue between the first two encodings.

Let’s see how this works in practice! We’ll start, as always, with a type of dogs:

> data Doggy = Tucker | Rover

We have introduced a type Doggy inhabited by two terms at the value-level; we have also introduced a kind 'Doggy inhabited by two terms at the type level. Now, we could create the “glue” GADT as follows:

data SDoggy :: Doggy → * where
  STucker :: SDoggy Tucker
  SRover  :: SDoggy Rover

But GHC provides a Sing type family under which we should create our singleton sets; this allows us to use some built-in machinery, like sing which allows one to infer the right singleton value for a known type. So, we’ll do the following:

> data instance Sing (d :: Doggy) where
>   STucker :: Sing Tucker
>   SRover  :: Sing Rover

We’ll need to help out with the inference instances:

> instance SingI Tucker where sing = STucker
> instance SingI Rover  where sing = SRover

And finally, we need to provide conversion from the singleton type to the plain-old-value type:

> instance SingE (Kind :: Doggy) Doggy where
>   fromSing STucker = Tucker
>   fromSing SRover  = Rover

It’s clear what this does, but it might not be immediately obvious what the (Kind :: Doggy) business is. Basically, Haskell does not currently allow one to abstract over kinds in a straight-forward way. Since we’re basically trying to make a map from kinds to types (that is, from the kind which -XDataKinds generated to the type whence it arose), we need to pass the kind in as the annotation to a dummy type; in this case, we use Kind, which is provided by GHC.TypeLits, and has no actual meaning by itself.

As you can see, all this boilerplate could in fact be generated with Template Haskell. In fact, the Singletons package already does so, but it does not use GHC’s built-in kit, so there’s a bit of unhappiness there.

Update: The Singletons package has been updated, and is now compatible with TypeLits.

Singletons for Higher Order Types

Before we get started, now would be a good time to introduce some naughty little shorthands that will make our code a bit less noisy:

> type Π = Sing
> π = fromSing

The capital Π adds a bit of swagger to our dependent function types. Combined with -XViewPatterns, π lets us pattern match on singleton parameters.

The procedure for higher order types (like lists, pairs, etc.) is basically the same as the above. Just a bit more involved; we’ll start with lists:

> data instance Sing (xs :: [k]) where
>   SNil :: Sing '[]
>   SCons :: Π (x :: k) → Π (xs :: [k]) → Sing (s ': xs)

> instance SingI '[] where sing = SNil
> instance (SingI x, SingI xs) ⇒ SingI (x ': xs) where
>   sing = SCons (sing :: Sing x) (sing :: Sing xs)

> instance SingE (Kind :: k) r ⇒ SingE (Kind :: [k]) [r] where
>   fromSing SNil = []
>   fromSing (SCons x xs) = fromSing x : fromSing xs

> data instance Sing (p :: (a,b)) where
>   SPair :: Sing a → Sing b → Sing '(a,b)

> instance (SingE (Kind :: a) x, SingE (Kind :: b) y) ⇒
>          SingE (Kind :: (a,b)) (x,y) where
>   fromSing (SPair x y) = (fromSing x, fromSing y)
> instance (SingI k, SingI v) ⇒ SingI '(k,v) where
>   sing = SPair sing sing

Sigma Types: Yes, We Can (to a point)

Consider the following definition, adapted from Data.Products in the Agda standard library:

record Σ {a b} (A : Set a) (B : A → Set b) : Set (a ⊔ b) where
  construct _,_
  field
    proj₁ : A
    proj₂ : B proj₁

This is the classic definition of a dependent sum in Agda. Basically, the first field is a type of some sort, and the second field is a proof that that type satisfies some predicate. Minus the record accessor sugar, the constructor _,_ comes out as the following:

data Σ {a b} (A : Set a) (B : A → Set b) : Set (a ⊔ b) where
  _,_ : (proj₁ : A) → B proj₁ → Σ A B

We would hope to be able to create something analogous in Haskell under the limited encoding of dependent types possible using singletons.

Now, as you can see, the Agda version is very flexible in terms of the sorts of things it can quantify, because of its use of universe polymorphism. Now, we can’t hope for anything quite as profound in Haskell; we’ll settle for having the second parameter be a predicate over terms of some kind, which is supplied in the first parameter.

We can now create the following definition:

data Σ (kind :: k) (pred :: k → *) where
  (:|-) :: Π (x :: k) → pred x → Σ kind pred

Note that this is equivalent to the following (minus our little Π shorthand which we use in the spirit of dependent types):

data Σ (kind :: k) (pred :: k → *) where
  (:|-) :: Sing x → pred x → Σ kind pred

Last, we put the final touches on by making this into a record:

> data Σ (kind :: k) (pred :: k → *) where
>   (:|-) :: { proj₁ :: Π (x :: k), proj₂ :: pred x } → Σ kind pred

Since in most cases, the kind over which the predicate operates is inferrable from the predicate itself, we provide the following convenience synonym:

> type Exists (pred :: k → *) = Σ Kind pred

So, we could, for instance, make a function that takes a number which is not one:

> data NotOne :: Nat → * where
>   NotOneZ :: NotOne 0
>   NotOneSS :: NotOne (n + 2)

> cantTakeOne :: Fractional t ⇒ Exists NotOne → t
> cantTakeOne ((π → n) :|- _) = 10.0 / (fromInteger n - 1)

We can also show that our Haskell encoding really is similar to the Agda version by providing our own version of the encoding of cartesian products (remember, a cartesian product arises when the predicate ignores its parameter).

If it were possible to have type-level lambdas in Haskell, then this would be just as simple as in Agda:

type x & y = Σ x (λ _ → y)

Unfortunately, we must actually provide a little bit of indirection to get around this limitation:

> type x & y = Σ x (Const y)
> data Const :: l → k → * where
>   Const :: Π (x :: l) → Const (Kind :: l) y

As such, to hide away the Const indirection, we’ll need to provide our own constructors and eliminators for products:

> (&) :: Π (x :: l) → Π (y :: k) → (Kind :: l) & (Kind :: k)
> x & y = x :|- Const y

> prodElim :: SingI pair ⇒ (Kind :: l) & (Kind :: k) → Sing (pair :: (l,k))
> prodElim _ = sing

Looks like our kit should be sufficient to make a pair of dogs:

> dawgFriends = STucker & SRover

A dependent head function over lists

There are several common ways to make a safe head function, many of which I have discussed in the past. Some of these involve having the function operate on lists which are non-empty by construction (using a length-indexed vector, or a list type which has no nil). If our list, however, exists at both the value and the type levels, we can just predicate over it without changing the structure of the list itself. Consider the following NonEmpty predicate:

> data NonEmpty :: [k] → * where
>   NonEmpty :: NonEmpty (x ': xs)

We can provide this as the predicate to our dependent sum!

> safeHead :: SingE (Kind :: k) r ⇒ Σ (Kind :: [k]) NonEmpty → r
> safeHead ((π → x : _) :|- _) = x

Note that we used a combination of -XViewPatterns and our little π shorthand to pattern match on the value-level reflection of the list. This definition is equivalent to the following:

safeHead ((SCons x xs) :|- _) = fromSing x

Safe Dictionary Lookup

We can do much the same thing with dictionaries:

> data HasKey :: l → [(l,k)] → * where
>   KeyHere  :: HasKey k ('(k, v) ': dict)
>   KeyThere :: HasKey k dict → HasKey k (pair ': dict)

> lookup :: (SingE (Kind :: k) k', SingE (Kind :: v) v') ⇒
>           Π (key :: k) →
>           Σ (Kind :: [(k,v)]) (HasKey key) → v'
> lookup _ ((π → (_,x) : _) :|- KeyHere)     = x
> lookup k (SCons _ xs      :|- KeyThere hk) = lookup k (xs :|- hk)

Of course, we can use the same trick as we always do by providing implicit proof terms:

> class Implicit x where
>   implicitly :: x
> instance Implicit (HasKey k ('(k,v) ': dict)) where
>   implicitly = KeyHere
> instance Implicit (HasKey k dict) ⇒ Implicit (HasKey k (pair ': dict)) where
>   implicitly = KeyThere implicitly

> lookup' k dict = lookup k (dict :|- implicitly)

> type DogNamesMap = ['(Tucker, "Tucker"), '(Rover, "Rover")]
> sDogNamesMap = sing :: Sing DogNamesMap

> tuckersName = lookup STucker (sDogNamesMap :|- KeyHere)
> tuckersName' = lookup' STucker sDogNamesMap

Caveats

That was fun! But this was mostly a demonstration to show that Σ-types are possible in Haskell, rather than a recommendation to use them. For one, it is a fair bit more complicated under this system to allow such functions to operate on dynamic data (which may or may not satisfy the static predicate), than under the system I proposed in my previous post.

Another thing which makes the singleton-encoding of dependent types rather unpleasant to use is the fact that whilst we can pretty easily reflect data up and down the ladder of universes, it’s rather more difficult to do the same with functions in a general way. So (at least today), you would have to write all your functions over such data as type families, and then reflect that down to the value level. This is probably possible, but it is indeed quite a lot to ask.

I’m hoping that the situation will continue to improve, though! GHC 7.6 finally made it possible (though not particularly pleasant) to do non-trivial kind abstraction. It is of great interest to me to see what is improved next.

Thanks for playing along!

To get started, extensible records just means a compositional approach to data structures, usually involving some kind of row polymorphism. So, given specifications for some record fields, we can get an expressive kind of static duck typing.

The Design

I’d like to make a few specifications about the final product:

1. It should take no more than one line of code to define each field.

2. Types should be locally inferrable.

3. The names of fields should be available without API consumers ever dealing with strings.

4. It should be possible to access fields with normal dot-syntax.

The Implementation

Field Representation

First, we’ll want to have an idea of what a field is. Let’s consider fields to be structures which are composed into larger structures using multiple inheritance. So, given a field like the following:

struct address { char const *address; };

We’ll want to expose some metadata about it.

template < class F         // the field structure (e.g. address)
         , class T         // the field's type (e.g. const char*)
         , T F::*ptr       // a path to the member (e.g. &address::address)
         , char const *sym // the field's name (e.g. "address")
         >
struct Field {
    typedef T Type;
    static T F::*access()       { return ptr; }
    static char const *symbol() { return sym; }
};

Making this metadata is quite simple:

extern char const address_sym[] = "address";
typedef Field<address, char const*, &address::address, address_sym> address_meta;

Note that we cannot instantiate the string template parameter directly in C++; we must provide it in a symbol with external linkage.

The problem now is twofold: first, we don’t want the user to have to enter in all this boilerplate, small as it is; secondly, we don’t have any way of deriving the metadata from the address struct itself. So, something a little bit more clever is called for!

Let’s make a static lookup-table:

template <class F> struct FieldTable {};

template <>
struct FieldTable<address>
  : Field<address, const char*, &address::address, address_sym>
{ };

And so we will now be able to access metadata for some field T using only FieldTable<T>! Now we’re getting somewhere. Let’s automate that:

#define mk_field(T, sym) \
    extern char const sym##_symbol[] = #sym;\
    struct sym { T sym; };\
    template <> struct FieldTable<sym> : Field<sym, T, &sym::sym, sym##_symbol> {};

Record Representation

A record is a just a variadic class template, defined inductively:

template <class... rows> struct Record;

The Base Case: The only thing we can do with an empty record is add something to it.

template <> struct Record<> {
    Record() { }

    template <class f>
    Record<f> insert(typename FieldTable<f>::Type val) const {
        Record<g> embiggened(*this); // make an enlarged record
        embiggened.*(FieldTable<f>::access()) = val;
        return embiggened;
    }
}

The Inductive Step: Herein lies the central conceit. We end up inheriting from every single field in the parameter list; we do this recursively (by inheriting from Record instantiated at the tail of the current parameter list).

template <class f, class... rows>
struct Record<f, rows...> : f, Record<rows...>
{

We need to enlarge records when inserting new fields. This is not entirely safe, but the presence of null in C++ means that it doesn’t make much of a difference.

    Record (const Record<rows...>& smaller) : Record<rows...>(smaller) { }

Our implementation for insert here is mostly the same as the one for the empty record; the type’s a tad different, though.

    template <class g>
    Record<g,f,rows...> insert(typename FieldTable<g>::Type val) const {
        Record<g,f,rows...> embiggened(*this);
        embiggened.*(FieldTable<g>::access()) = val;
        return embiggened;
    }

We allow the construction of a new record with the value to one field changed.

    template <class g>
    Record set(typename FieldTable<g>::Type val) const {
        Record copy(*this);
        copy.*(FieldTable<g>::access()) = val;
        return copy;
    }

We can also just pass in a function to modify the value:

    template <class T>
    using Endomorphism = std::function<T(T)>;

    template <class g>
    Record modify(Endomorphism<typename FieldTable<g>::Type> func) const {
        auto value = func(this->*(FieldTable<g>::access()));
        return set<g>(value);
    }
}

Pretty Printing

The fact that we provide the field’s name in our static metadata will come in handy now! It is the case that all records can be shot through an std::ostream!

std::ostream& operator<<(std::ostream& stream, const Record<>& empty) {
    return stream << "{}";
}

template <class f, class... rows>
std::ostream& operator<<(std::ostream& stream, const Record<f, rows...>& record) {
    Record<rows...> smaller = record;
    typedef FieldTable<f> field;
    return stream << field::symbol() << " : " << record.*(field::access()) << ", " << smaller;
}

Test Drive

We can play with the machinery we built now. Let’s first define a few fields:

mk_field(char const*, name);
mk_field(char const*, favorite_food);
mk_field(int, age);

We could even have put these in a namespace for extra safety. We can of course express a generic function which increments the age of any record which has that field:

template <class R>
R tick_tock(R const& rec) {
    return rec.template modify<age>([](int i) { return i + 1; });
}

Let’s try making up some records now:

void test_records() {
    const Record<> empty;
    const auto step1 = empty.insert<name>("jon");
    const auto step2 = step1.insert<age>(20);
    const auto step3 = step2.insert<favorite_food>("icecream");
    const auto step4 = step3.set<favorite_food>("calzone");
    const auto step5 = tick_tock(step3);

    std::cout << step1 << std::endl;
    // => name : jon, {}
    std::cout << step2 << std::endl;
    // => age : 20, name : jon, {}
    std::cout << step3 << std::endl;
    // => favorite_food : icecream, age : 20, name : jon, {}
    std::cout << step4 << std::endl;
    // => favorite_food : calzone, age : 20, name : jon, {}
    std::cout << step5.age << std::endl;
    // => 21
}

Next Steps

A few changes would have to be made to our design to allow for removing fields from records nicely: our record representation would have to be recursive rather than flat for the proper return type to be readily computable.

It would also be interesting to see how difficult it would be to derive generic equality for records using operator==.

Finally, the most interesting thing to do would be to have some notion of compositional lenses to allow deep update. For instance, imagine if the following were possible:

auto changed = man.modify<brother,dog,fur,color>("orange");

We'll begin with a very simple (and underpowered) theory of syntax including the following:

1. Syntactic categories: things like Noun, Verb, and Determiner. These classify items in our lexicon.
2. Merge: an operation that combines two nodes to make a larger node. Phrases are built from the lowest head upwards, by merging new nodes onto the head.
3. X-Bar Schema: There are at most two levels of projection from a single head; a head X may merge with an internal argument, projecting a X' node, which may in turn merge with an external argument to project the maximal XP node.

The internal argument is the sister of X, and is called its complement; the external argument is the aunt of X (the sister of X'), and is called the specifier. Therefore, the two kinds of merges that we have discussed are referred to as C-Merge and S-Merge respectively.

The schema looks something like this:

              XP                             X
             / \                            / \
            /   \                          /   \
           /     \                        /     \
          ZP     X'       (or just)      Z      X
                / \                            / \
               /   \                          /   \
              /     \                        /     \
             YP      X                      Y       X

The latter representation is the same, except the projection-level is left to be inferred.

In later posts, I'll revisit our theory with enhancements that will make it more able to express natural language syntax.

The Implementation

           V
          / \
         /   \
        /     \
       I      V
             / \
            /   \
           /     \
         love    D
                / \
               /   \
              /     \
             the    dog

Next steps

Basically, all that this theory provides us is the ability to base grammaticality-judgements of merges on the syntactic category of consituents and their arguments. This is obvously not enough! Not only do we need to make more interesting specifications than syntactic category, we also need to include the following notions: phrasal movement, agreement, and head movement, to name a few.

In addition, it would be prudent to escape the bonds that our current argument representation has left us in, and move toward a more minimal approach based on a single merge operation; in addition, a notion of feature strength (that is, whether a feature must be satisfied locally or not) would be an enormous improvement.

In the meanwhile, play around with the sources to this post and see what you can improve!

The Problem: Sometimes We Lie

Let’s go over the state of affairs. APIs accept strings for keypaths; we then conjure up some macro like @keypath to allow compile-time checking of keypaths, gaining in addition the ability for them to participate in refactoring. So, we can be sure that our own code is providing safe keypaths to the APIs it consumes.

[detailView bind: @keypath(detailView.titleLabel.text)
        toObject: dogsController
     withKeyPath: @keypath(dogsController.selectedDog.name)
         options: nil];

But the other half of the problem remains: when our own APIs use keypaths, it would be nice to enforce that these keypaths be checked. If we’re just accepting strings and hoping the client code is clever enough to use our @keypath macro, all is well until we begin to lie. And we all lie.

Trusted Boundaries: Types For Certified Keypaths

Whilst we really can’t do anything about Cocoa’s APIs, we should like to force keypaths passed into our own APIs to be checked. We can do this with a type, and some clever higgle-piggling about with deprecation annotations:²

1
2
3
4
5
6
7
8
9
10
11
12
13
14

@interface CheckedKeyPath : NSObject
@property (strong, readonly) NSString *stringValue;
- (id)initWithUnsafeKeyPath:(NSString *)unsafeKeyPath DEPRECATED_ATTRIBUTE;
@end

@interface NSString (CheckedKeyPath)
- (CheckedKeyPath *)unsafeMarshalKeyPath DEPRECATED_ATTRIBUTE;
@end

#define keypath(PATH) \
_Pragma("clang diagnostic push")\
_Pragma("clang diagnostic ignored \"-Wdeprecated\"")\
    (strchr(# PATH, '.') + 1).unsafeMarshalKeypath \
_Pragma("clang diagnostic pop")

Now, the real trick is in the @keypath macro definition above; feel free to swap in something more advanced for the meat of the definition. The important part is that the macro includes pragmas³ to suppress warnings about deprecated methods, and then goes ahead and uses -unsafeMarshalKeypath in that scope. In this way, we can be reasonably assured (though not entirely, of course) that the only way anyone will ever create a term of type CheckedKeyPath is by using this macro.

Now, in our APIs, we can expose only safe interfaces for keypaths by accepting CheckedKeyPath rather than NSString; when a keypath needs to be passed to Cocoa, we can then trivially throw away the certification by sending -stringValue.

1. Mutation methods only occur in the interfaces for the mutable variants. This protects us when types are preserved.
2. Sending a mutation message to an immutable object results in an exception.

I’m going to argue that the first force of protection (that of types) is far more important than the second (that of runtime exceptions), and that if we are willing to give it up, we can have a vastly simpler notion of immutability and mutability. Finally, I’ll discuss ways we can recover runtime exceptions in the case of an unsafe cast, and finally how we can recover the functionality of -mutableCopy in a subclass-friendly fashion.

Immutability: Axioms for a Minimal Implementation

Let us agree on the following axioms (that is to say, the extent to which you find this article valuable will vary with the extent to which you stipulate the following):

1. Objects should be immutable; no shared object should ever have its state changed underneath from another object. If multiple objects need to share the changing state of another object, it should be represented as a reactive event stream.

2. It should be trivial to make an updated copy of an object; it should be trivial to update multiple aspects of an object in whichever order you wish.

3. We need not code defensively against unsafe casting. If API consumers perform a downward cast, they objectively deserve every bit of bizarre and confusing behavior they are rewarded with.

And so from Axiom 3, we can dispatch the issue of whether it is necessary to have both static and runtime assurances about immutability. If API consumers agree not to perform any obviously unsafe casts, then we can rely on static immutability alone. Later we’ll discuss what is necessary if we wish to discard this last axiom.

Implementation Example: An Ordered Dictionary

The key conceit of our plan is to provide a mutable and an immutable interface to an object; then, we limit access to the mutable interface to a few safe points in our code. That is, we will allow dictionaries to be built and updated imperativiely, but the mutations will be upon a copy. It should look something like this:

JSOrderedDictionary *updated = [oldDict update:^(id<JSMutableOrderedDictionary> dict) {
    dict[@"dogs"] = @[ @"tucker", @"rover" ];
    dict[@"cats"] = @[ @"emma" ];
    [dict removeObjectForKey:@"hamsters"];
}];

Now, we can get started. First, we will define the immutable and mutable interfaces for an ordered dictionary; we expose the mutable one only in -update:. The mutable interface of course inherits all the immutable kit.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

@protocol JSMutableOrderedDictionary;
typedef void (^JSOrderedDictionaryUpdate)(id<JSMutableOrderedDictionary> dict);

@protocol JSOrderedDictionary <NSFastEnumeration>
- (id)objectForKey:(id<NSCopying>)key;
- (id)objectForKeyedSubscript:(id<NSCopying>)key;

- (NSArray *)allKeys;
- (NSArray *)allValues;
- (NSUInteger)count;

- (instancetype)update:(JSOrderedDictionaryUpdate)updateBlock;
@end

@protocol JSMutableOrderedDictionary <JSOrderedDictionary>
- (void)setObject:(id)object forKey:(id<NSCopying>)key;
- (void)setObject:(id)object forKeyedSubscript:(id<NSCopying>)key;
- (void)removeObjectForKey:(id<NSCopying>)key;
@end

@interface JSOrderedDictionary : NSObject <JSOrderedDictionary, NSCopying>
- (id)initWithOrderedDictionary:(id<JSOrderedDictionary>)dictionary;
- (id)initWithObjects:(NSArray *)objects forKeys:(NSArray *)keys;
@end

The implementation is quite straightforward:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78

@interface JSOrderedDictionary (JSMutableOrderedDictionary) <JSMutableOrderedDictionary>
@end

@implementation JSOrderedDictionary {
    NSMutableArray *_keys;
    NSMutableDictionary *_dictionary;
}

#pragma mark - Initializers

- (id)init {
    return [self initWithObjects:@[ ] forKeys:@[ ]];
}

- (id)initWithOrderedDictionary:(id<JSOrderedDictionary>)dictionary {
    return [self initWithObjects:dictionary.allValues forKeys:dictionary.allKeys];
}

- (id)initWithObjects:(NSArray *)objects forKeys:(NSArray *)keys {
    if (self = [super init]) {
        _keys = [keys mutableCopy];
        _dictionary = [NSMutableDictionary dictionaryWithObjects:objects forKeys:keys];
    }

    return self;
}

#pragma mark - NSCopying

- (id)copyWithZone:(NSZone *)zone {
    return [[[self class] alloc] initWithOrderedDictionary:self];
}

#pragma mark - NSFastEnumeration

- (NSUInteger)countByEnumeratingWithState:(NSFastEnumerationState *)state
     objects:(__unsafe_unretained id [])buffer count:(NSUInteger)len {
    return [_keys countByEnumeratingWithState:countByEnumeratingWithState:state objects:buffer count:len];
}

#pragma mark - JSOrderedDictionary

- (id)objectForKey:(id<NSCopying>)key {
    return [_dictionary objectForKey:key];
}

- (id)objectForKeyedSubscript:(id<NSCopying>)key {
    return [self objectForKey:key];
}

- (NSArray *)allKeys {
    return [_keys copy];
}

- (NSArray *)allValues {
    NSMutableArray *values = [NSMutableArray arrayWithCapacity:self.count];
    for (id<NSCopying> key in self) {
        [values addObject:self[key]];
    }

    return [values copy];
}

- (NSUInteger)count {
    return _keys.count;
}

- (instancetype)update:(JSOrderedDictionaryUpdate)updateBlock {
    JSOrderedDictionary *copy = [self copy];
    updateBlock(copy);
    return copy;
}

@end

@implementation JSOrderedDictionary (JSMutableOrderedDictionary)
// The implementation is trivial.
@end

Fudging the Axioms: What can we recover?

Now that we’ve shown the Taliban approach, we can see what is necessary to recover some of the things we might miss.

Recovering Exceptions

As explained above, the current model expresses the boundary between mutability and immutability using types. That is, we provide a mutable interface to our dictionary, exposed in such a way as to aggregate imperative updates and perform them safely on a copy. But we do nothing to prevent a user from casting JSOrderedDictionary to id<JSMutableOrderedDictionary>; if a dictionary object is shared, and one partaker unscrupulously (and unsafely) casts the dictionary to id or the mutable interface, this may represent a broken program that would be hard to debug.

We can recover exceptions (which would provide a way to determine when a dictionary is being used unsafely) very simply by adding a private flag to the dictionary:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

@implementation JSOrderedDictionary {
    BOOL _isMutable;
    // ...
}

- (instancetype)modify:(JSOrderedDictionaryUpdate)block {
    JSOrderedDictionary *copy = [self copy];
    copy->_isMutable = YES;
    block(copy);
    copy->_isMutable = NO;
    return copy;
}

// ...
@end

@implementation JSOrderedDictionary (JSMutableOrderedDictionary)

- (void)assertMutableForSelector:(SEL)selector {
    if (_isMutable) return;

    NSString *reason = [NSString stringWithFormat:
                        @"Attempted to send -%@ to immutable object %@",
                        NSStringFromSelector(selector), self];
    @throw [NSException exceptionWithName:NSInternalInconsistencyException reason:reason userInfo:nil];
}

- (void)setObject:(id)object forKey:(id<NSCopying>)key {
    NSParameterAssert(key != nil);
    [self assertMutableForSelector:_cmd];

    if (object == nil) [_keys removeObject:key];
    else if (![_keys containsObject:key]) {
        [_keys addObject:key];
    }

    [_dictionary setObject:object forKey:key];
}

// ...

@end

Mutability Unchained: Omphale’s Revenge

We can even recover the last remaining thing that the class cluster approach gives us (to have a real mutable dictionary, at your own peril) by adding a bit more kit. Let’s wipe out what we did in the last section and refine it a bit. First, let’s adopt <NSMutableCopying> to our interface:

1
2
3

@interface JSOrderedDictionary : NSObject <JSOrderedDictionary, NSCopying, NSMutableCopying>
// ...
@end

Now for some new kit:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

typedef enum {
    JSMutabilityNone,
    JSMutabilityTemporary,
    JSMutabilityPermanent
} JSMutabilityState;

@implementation JSOrderedDictionary {
    JSMutabilityState _mutabilityState;
    // ...
}

- (void)performWithTemporaryMutability:(JSOrderedDictionaryUpdate)block {
    BOOL immutableByDefault = _mutabilityState != JSMutabilityPermanent;
    if (immutableByDefault) _mutabilityState = JSMutabilityTemporary;
    block(self);
    if (immutableByDefault) _mutabilityState = JSMutabilityNone;
}

- (instancetype)modify:(JSOrderedDictionaryUpdate)block {
    BOOL immutableByDefault = _mutabilityState != JSMutabilityPermanent;
    JSOrderedDictionary *copy = immutableByDefault ? [self copy] : [self mutableCopy];
    [copy performWithTemporaryMutability:^(id<JSMutableOrderedDictionary> dict) {
        block(dict);
    }];
    return copy;
}

#pragma mark - NSMutableCopying

- (id)mutableCopyWithZone:(NSZone *)zone {
    JSOrderedDictionary *copy = [self copyWithZone:zone];
    copy->_mutabilityState = JSMutabilityPermanent;
    return copy;
}

@end

@implementation JSOrderedDictionary (JSMutableOrderedDictionary)

- (void)assertMutableForSelector:(SEL)selector {
    if (_mutabilityState != JSMutabilityNone) return;
    // ...
}

@end

The beauty of this approach is that it is now possible to provide full mutability by adding only a tiny bit of code to the immutable implementation, in a way that is very friendly to subclasses.

Whereas with class clusters, for a class cluster {A_mutable, A_immutable}, a subclass B which wishes to provide correct behavior must provide {B_mutable < A_mutable, B_immutable < A_mutable}; furthermore, methods having free ocurrences of A_mutable must be rewritten in the subclass to use B_mutable and so forth.

Our approach sidesteps these problems quite nicely.

Parting Notes

I’m using this approach for ordered dictionaries in ReactiveFormlets. It seems sufficient for my purposes; I’m excited to see if it will do for more advanced ones.

First, let’s come up with some notion of equality. We’re going to base our encoding off of the following pseudocode:

$\begin{align} \frac{\vdash\sigma : \star \qquad \vdash\tau : \star}{\vdash \sigma \equiv \tau : \star}\tag{≡-type} \end{align}$

$\begin{align} \frac{\vdash\sigma : \star}{\vdash\ \hbox{refl} : \sigma\equiv\sigma}\tag{≡-intro} \end{align}$

$\begin{align} \frac{\vdash x : \sigma \qquad \sigma\equiv\tau}{\vdash x : \tau}\tag{≡-conversion} \end{align}$

$\begin{align} \frac{\vdash \sigma\equiv\tau \qquad \vdash f : \star\to\star}{\vdash f(\sigma)\equiv f(\tau)}\tag{≡-congruence} \end{align}$

$\begin{align} \frac{\vdash \sigma\equiv\tau \qquad \vdash f : \star\to\star\qquad \vdash x : f(\sigma)}{\vdash x : f(\tau)} \tag{≡-transport} \end{align}$

Encoding Equality

#include <functional>
namespace Equality {

There is no term in ∀ A B. Eq<A,B>; constructors are automatically generated by C++, so we must explicitly delete it.

    template <class A, class B>
    struct Eq { Eq() = delete; };

According to $\hbox{≡-intro}$ rule above, we can construct a term in ∀ A. Eq<A,A>:

    template <class A>
    struct Eq<A,A> { Eq() {} };

Casting as in $\hbox{≡-conversion}$ is morally correct, but not provable in C++, lacking any notion of dependent pattern matching and refinement. Trusting in the soundness of our axioms, we do an unsafe cast under the hood, given an equality proof.

    template <class A, class B>
    B cast(Eq<A,B> refl, A x) {
        return *(B*)&x;
    }

Likewise, $\hbox{≡-congruence}$ is not provable in C++ for the same reasons; we’ll have to fudge the implementation, trusting the axioms.

    template <template <class> class F, class A, class B>
    Eq<F<A>,F<B>> cong(Eq<A,B> refl) {
        auto fudge = Eq<F<A>,F<A>>();
        return *(Eq<F<A>,F<B>>*)&fudge;
    }

Finally, $\hbox{≡-transport}$ can be defined in terms of what we’ve already done:

    template <template <class> class F, class A, class B>
    F<B> transport(Eq<A,B> refl, F<A> x) {
        return cast(cong<F>(refl), d);
    }
}

Encoding some Logic

In a quick digression that will prove necessary shortly, let’s define some basic types that will correspond to falsity, truth and negation:

namespace Logic {

In the BHK interpretation of intuitionistic logic, falsity is simply a proposition that has no proofs. So we can just provide a type without any constructors:

    struct Empty { Empty() = delete; };

To make a provable proposition, we can provide a type that does have a constructor:

    struct Unit { Unit () {} };

For one proposition P to imply another proposition Q, we provide a function which converts proofs of P to proofs of Q:

    template <class P, class Q>
    using Implication = std::function<Q(P)>;

Finally, we use reductio ad absurdum to refute a proposition:

    template <class P>
    using Not = Implication<P,Empty>;
}

Discrimination: Refuting Equalities

Finally, we are ready to encode the central conceit.

namespace Refute {
    using namespace Logic;
    using namespace Equality;

First, we shall encode some type-level discrimination functions; so that we can branch on types:

    template <class A, class B, class T, class CaseA, class CaseB> struct If;

    template <class A, class B, class CaseA, class CaseB>
    struct If<A,B,A,CaseA,CaseB> {
        using apply = CaseA;
    };

    template <class A, class B, class CaseA, class CaseB>
    struct If<A,B,B,CaseA,CaseB> {
        using apply = CaseB;
    };

Because of some quirks in the way that C++ handles partial template application, we must provide a bit of indirection for what comes next:

    template <class A, class B>
    struct Discriminate {
        template <class T>
        using apply = typename If<A,B,T,Unit,Empty>::apply;
    };

If a path from A to B (in Eq<A,B>) actually exists, then we should be able to transport any F<A> to F<B>; in this way, we can convert a proof of Eq<A,B> to a proof of Empty.

    template <class A, class B>
    typename Discriminate<A,B>::template apply<B> refute_equality(Eq<A,B> refl) {
        return transport<Discriminate<A,B>::template apply>(refl, Unit());
    }
}

The Payoff

Now, given some different types, we can prove that they are not equal using the kit that we have come up with so far:

void demonstration() {
    using Equality::Eq;
    using Logic::Not;
    using Refute::refute_equality;

    struct Dog;
    struct Cat;

    Not<Eq<Cat,Dog>> cat_is_not_dog = refute_equality<Cat,Dog>;
}

The term cat_is_not_dog serves as a witness that Cat and Dog are different types!

First, install Vinyl from Hackage:

cabal update
cabal install vinyl

Let’s work through a quick example. We’ll need to enable some language extensions first:

> {-# LANGUAGE DataKinds, TypeOperators #-}
> {-# LANGUAGE FlexibleContexts, NoMonomorphismRestriction #-}

> import Data.Vinyl
> import Data.Vinyl.Unicode
> import Data.Vinyl.Validation
> import Control.Applicative
> import Control.Monad.Identity
> import Data.Char

Let’s define the fields we want to use:

> name     = Field :: "name"     ::: String
> age      = Field :: "age"      ::: Int
> sleeping = Field :: "sleeping" ::: Bool

Now, let’s try to make an entity that represents a man:

> jon = name =: "jon"
>    <+> age =: 20
>    <+> sleeping =: False

We could make an alias for the sort of entity that jon is:

> type LifeForm = ["name" ::: String, "age" ::: Int, "sleeping" ::: Bool]
> jon :: PlainRec LifeForm

The types are inferred, though, so this is unnecessary unless you’d like to reuse the type later. Now, make a dog! Dogs are life-forms, but unlike men, they have masters. So, let’s build my dog:

> master = Field :: "master" ::: PlainRec LifeForm

> tucker = name =: "tucker"
>       <+> age =: 7
>       <+> sleeping =: True
>       <+> master =: jon

Using Lenses

Now, if we want to wake entities up, we don’t want to have to write a separate wake-up function for both dogs and men (even though they are of different type). Luckily, we can use the built-in lenses to focus on a particular field in the record for access and update, without losing additional information:

> wakeUp :: (("sleeping" ::: Bool) ∈ fields) => PlainRec fields -> PlainRec fields
> wakeUp = sleeping `rPut` False

Now, the type annotation on wakeUp was not necessary; I just wanted to show how intuitive the type is. Basically, it takes as an input any record that has a BOOL field labelled sleeping, and the modifies that specific field in the record accordingly.

> tucker' = wakeUp tucker
> jon' = wakeUp jon

We can also access the entire lens for a field using the rLens function; since lenses are composable, it’s super easy to do deep update on a record:

> masterSleeping :: (("master" ::: PlainRec LifeForm) ∈ fields) => SimpleLens (PlainRec fields) Bool
> masterSleeping = rLens master . rLens sleeping

> tucker'' = masterSleeping .~ True $ tucker'

Again, the type annotation is unnecessary. In fact, the seperate definition is also unnecessary, and we could just define:

> tucker''' = rLens master . rLens sleeping .~ True $ tucker'

Subtyping Relation and Coercion

A record PlainRec xs is a subtype of a record PlainRec ys if ys ⊆ xs; that is to say, if one record can do everything that another record can, the former is a subtype of the latter. As such, we should be able to provide an upcast operator which “forgets” whatever makes one record different from another (whether it be extra data, or different order).

Therefore, the following works:

> upcastedTucker :: PlainRec LifeForm
> upcastedTucker = cast (fixRecord tucker)

The reason for using fixRecord will become clear a bit later.

The subtyping relationship between record types is expressed with the (<:) constraint; so, cast is of the following type:

cast :: r1 <: r2 => r1 -> r2

Also provided is a (≅) constraint which indicates record congruence (that is, two record types differ only in the order of their fields).

Records are polymorphic over functors

So far, we’ve been working with the PlainRec type; but below that, there is something a bit more advanced called Rec, which looks like this:

data Rec :: [*] -> (* -> *) -> * where
  RNil :: Rec '[] f
  (:&) :: (r ~ (sy ::: t)) => f t -> Rec rs f -> Rec (r ': rs) f

The second parameter is a functor, in which every element of the record will be placed. In PlainRec, the functor is just set to Identity. Let’s try and motivate this stuff with an example.

Let’s imagine that we want to do validation on a record that represents a name and an age:

> type Person = ["name" ::: String, "age" ::: Int]

We’ve decided that names must be alphabetic, and ages must be positive. For validation, we’ll use a type that’s included here called Result e a, which is similar to Either, except that its Applicative instance accumulates monoidal errors on the left.

> goodPerson :: PlainRec Person
> goodPerson = name =: "Jon"
>          <+> age =: 20

> badPerson = name =: "J#@#$on"
>          <+> age =: 20

> validatePerson :: PlainRec Person -> Result [String] (PlainRec Person)
> validatePerson p = (\n a -> name =: n <+> age =: a) <$> vName <*> vAge where
>   vName = validateName (rGet name p)
>   vAge  = validateAge  (rGet age p)
> 
>   validateName str | all isAlpha str = Success str
>   validateName _ = Failure [ "name must be alphabetic" ]
>   validateAge i | i >= 0 = Success i
>   validateAge _ = Failure [ "age must be positive" ]

The results are as expected (Success for goodPerson, and a Failure with one error for badPerson); but this was not very fun to build.

Further, it would be nice to have some notion of a partial record; that is, if part of it can’t be validated, it would still be nice to be able to access the rest. What if we could make a version of this record where the elements themselves were validation functions, and then that record could be applied to a plain one, to get a record of validated fields? That’s what we’re going to do.

Vinyl provides a type of validators, which is basically a natural transformation from the Identity functor to the Result functor, which we just used above.

type Validator e = Identity ~> Result e

Let’s parameterize a record by it: when we do, then an element of type a should be a function Identity a -> Result e a:

> vperson :: Rec Person (Validator [String])
> vperson = NT validateName :& NT validateAge :& RNil where
>    validateName (Identity str) | all isAlpha str = Success str
>    validateName _ = Failure [ "name must be alphabetic" ]
>    validateAge (Identity i) | i >= 0 = Success i
>    validateAge _ = Failure [ "age must be positive" ]

And we can use the special application operator <<*>> (which is analogous to <*>, but generalized a bit) to use this to validate a record:

> goodPersonResult = vperson <<*>> goodPerson
> badPersonResult  = vperson <<*>> badPerson

goodPersonResult === name :=: Success "Jon", age :=: Success 20, {}
badPersonResult  === name :=: Failure ["name must be alphabetic"], age :=: Success 20, {}

So now we have a partial record, and we can still do stuff with its contents. Next, we can even recover the original behavior of the validator (that is, to give us a value of type Result [String] (PlainRec Person) using run:

> runGoodPerson = run goodPersonResult
> runBadPerson  = run badPersonResult

runGoodPerson === Success name :=: "Jon", age :=: 20, {}
runBadPerson  === Failure ["name must be alphabetic"]

Fixing a polymorphic record into the Identity Functor

If you produced a record using (=:) and (<+>) without providing a type annotation, then its type is something like this:

record :: Applicative f => Record [ <bunch of stuff> ] f

The problem is then we can’t do anything with the record that requires us to know what its functor is. For instance, cast will fail. So, we might try to provide a type annotation, but that can be a bit brittle and frustrating to have to do. To alleviate this problem, fixRecord is provided:

fixRecord :: (forall f. Applicative f => Rec rs f) -> PlainRec rs

First, let us pry open the pandora’s box; some of these wights are more dangerous than others.

> {-# LANGUAGE PolyKinds              #-}
> {-# LANGUAGE DataKinds              #-}
> {-# LANGUAGE FunctionalDependencies #-}
> {-# LANGUAGE GADTs                  #-}
> {-# LANGUAGE FlexibleContexts       #-}
> {-# LANGUAGE FlexibleInstances      #-}
> {-# LANGUAGE KindSignatures         #-}
> {-# LANGUAGE LambdaCase             #-}
> {-# LANGUAGE RankNTypes             #-}
> {-# LANGUAGE TypeOperators          #-}
> {-# LANGUAGE UndecidableInstances   #-}
> {-# LANGUAGE UnicodeSyntax          #-}

> module STLC where

The Syntax of the STLC

First, we will begin with a type-free syntax of terms generating a universe with a predicative hierarchy of sets:

> data Term
>   = Set Term       -- ^ predicative sets
>   | (~>) Term Term -- ^ the function arrow
>   | ℕ              -- ^ natural numbers
>   | Z              -- ^ zero
>   | S Term         -- ^ successor
>   | Λ Term         -- ^ abstraction
>   | (#) Term Term  -- ^ application
>   | V Term         -- ^ variables

It may seem odd that, for instance, we parameterize Set and V by Term, since it’s clear that we should want natural numbers there. But this will get nailed down when we make our family of typing rules.

Contexts are either empty or are extended by a type:

> data Cx
>   = E
>   | (:>) Term Cx

Typing Rules for the STLC

With the addition of a dirty little bit of syntactic sugar, we can now present the typing rules of our system.

> type x ⊢ f = f x
> infixr 5 ⊢

I’ve decided to arrange these rules in a natural-deduction style presentation. A term of type γ ⊢ x ∈ τ says that “the context γ proves that x is of type τ”; this is called a typing derivation.

> data (∈) :: Term → Term → Cx → ★ where

There is an infinite hierarchy of sets, where each is the type of the previous, down to the base case, which is the type of small types.

>   TSet  ::           E ⊢ n ∈ ℕ
>           --------------------------------
>          →      γ ⊢ Set n ∈ Set (S n)

ℕ is a small type.

>   TNat  :: -------------------------------
>                    γ ⊢ ℕ ∈ Set Z

Z is a natural number.

>   TZ    :: -------------------------------
>                       γ ⊢ Z ∈ ℕ

Given a natural number n, S n is also a natural number.

>   TS    ::            γ ⊢ n ∈ ℕ
>           --------------------------------
>          →           γ ⊢ S n ∈ ℕ

Given a term l of type τ a context extended by σ, Λ l is of type σ ~> τ.

>   TLam  ::        σ :> γ ⊢ l ∈ τ
>           --------------------------------
>          →       γ ⊢ Λ l ∈ (σ ~> τ)

Given a term f in σ ~> τ and a term x in σ, f # x is in τ.

>   TApp  ::  γ ⊢ f ∈ (σ ~> τ) → γ ⊢ x ∈ σ
>           --------------------------------
>          →         γ ⊢ f # x ∈ τ

Now we provide evidence that a variable of a given type is within a context.

>   TVTop :: -------------------------------
>                  τ :> γ ⊢ V Z ∈ τ
>   TVPop ::   E ⊢ i ∈ ℕ   →   γ ⊢ V i ∈ σ
>           --------------------------------
>          →     τ :> γ ⊢ V (S i) ∈ σ

Computing Typing Derivations for Terms

type PlusOne = Λ (S (V Z))
plusOne :: E ⊢ PlusOne ∈ (ℕ ~> ℕ)
plusOne = TLam (TS TVTop)

We of course can also just have our expressions in-line:

plusOne' :: E ⊢ (Λ S (V Z)) ∈ (ℕ ~> ℕ)
plusOne' = TLam (TS TVTop)

It would be nice if we could get the process of generating typing derivations automated for us! Since it’s the case that the typing derivation for well-typed expressions usually resembles the structure of the term very nicely anyway, this should be possible. We can start with this type class:

> class Infer (x :: Term) (τ :: Term) (γ :: Cx) | x γ → τ where
>   infer :: γ ⊢ x ∈ τ

It turns out that we’ll basically just be recapitulating the typing rules wholesale, in such a way as to get Haskell’s constraint solver to infer them for us:

> instance Infer ℓ ℕ E ⇒ Infer (Set ℓ) (Set (S ℓ)) γ where
>   infer = TSet infer
> instance Infer Z ℕ γ where
>   infer = TZ
> instance Infer n ℕ γ ⇒ Infer (S n) ℕ γ where
>   infer = TS infer

> instance Infer l τ (σ :> γ) ⇒ Infer (Λ l) (σ ~> τ) γ where
>   infer = TLam infer
> instance (Infer f (σ ~> τ) γ, Infer x σ γ) ⇒ Infer (f # x) τ γ where
>   infer = TApp infer infer

> instance Infer (V Z) τ (τ :> γ) where
>   infer = TVTop
> instance (Infer i ℕ E, Infer (V i) σ γ) ⇒ Infer (V (S i)) σ (τ :> γ) where
>   infer = TVPop infer infer

Then, we can make a type for closed expressions that have an inferrable type:

> type Closed e = Infer e τ E ⇒ E ⊢ e ∈ τ

fst :: Closed (Λ (Λ (V (S Z))))
fst = infer

snd :: Closed (Λ (Λ (V Z)))
snd = infer

Appendix: Pretty Pretting

> instance Show (γ ⊢ x ∈ t) where
>   show (TSet ℓ) = "Set" ++ (show . Sub . natToInt $ ℓ)
>   show TNat = "ℕ"
>   show TZ = "Z"
>   show (TS n) = "S (" ++ show n ++ ")"
>   show (TLam l) = "λ. " ++ show l
>   show (TApp f x) = "(" ++ show f ++ ")" ++ " " ++ "(" ++ show x ++ ")"
>   show TVTop = "v" ++ show (varToInt TVTop)
>   show (TVPop _ i) = "v" ++ (show . Sub . varToInt $ i)

> varToInt :: γ ⊢ V i ∈ σ → Int
> varToInt TVTop = 0
> varToInt (TVPop _ i) = 1 + varToInt i

> natToInt :: γ ⊢ n ∈ ℕ → Int
> natToInt TZ = 0
> natToInt (TS i) = 1 + natToInt i
> natToInt _ = error "non-canonical natural number"

> newtype Subscript = Sub Int
> instance Show Subscript where
>   show (Sub n) = fmap trans (show n) where
>     trans =
>       \case
>         '0' → '₀'
>         '1' → '₁'
>         '2' → '₂'
>         '3' → '₃'
>         '4' → '₄'
>         '5' → '₅'
>         '6' → '₆'
>         '7' → '₇'
>         '8' → '₈'
>         '9' → '₉'
>         d   → d

Read the paper here: Antigone-Projectivity.pdf

Phaedrus and his derivatives

Phaedrus’s speech may be understood as the basis for a theory of Eros which is developed and augmented all the way through the speeches of Pausanias and Eryximachus. If we put aside Phaedrus’s initial mythological appeals, the main focus of Phaedrus’s speech, then, would seem to be the power of Eros to engender in humans a kind of virtue or fury which they might not have had without the god’s inspiration.

When Pausanias begins, he criticizes Phaedrus for failing to include in his account the fact that Eros is double in nature:

εἰπεῖν δ’ αὐτὸν ὅτι Οὐ καλῶς μοι δοκεῖ, ὦ Φαῖδρε, προβεβλῆσθαι ἡμῖν ὁ λόγος, τὸ ἁπλῶς οὕτως παρηγγέλθαι ἐγκωμιάζειν Ἔρωτα. εἰ μὲν γὰρ εἷς ἦν ὁ Ἔρως, καλῶς ἂν εἶχε, νῦν δὲ οὐ γάρ ἐστιν εἷς· μὴ ὄντος δὲ ἑνός ὀρθότερόν ἐστι πρότερον προρηθῆναι ὁποῖον δεῖ ἐπαινεῖν.¹ (180c3–180d1)

But Pausanias’s analysis is necessarily a refinement of Phaedrus’s, and not a refutation. In fact, Pausanias only adds and does not subtract from Phaedrus’s point; for he simply specifies further both the nature and the origin of the inspiration that Phaedrus discussed, integrating it into his dual understanding of Eros. In Pausanias’s framework, this inspiration is nothing other than the engenderment of concern for virtue in the hearts of lovers and their beloveds; and this is, to be sure, the inspiration which is derived from the Heavenly Eros, as opposed to the other:

οὗτός ἐστιν ὁ τῆς οὐρανίας θεοῦ ἔρως καὶ οὐράνιος καὶ πολλοῦ ἄξιος καὶ πόλει καὶ ἰδιώταις, πολλὴν ἐπιμέλειαν ἀναγκάζων ποιεῖσθαι πρὸς ἀρετὴν τόν τε ἐρῶντα αὐτὸν αὑτοῦ καὶ τὸν ἐρώμενον· οἱ δ’ ἕτεροι πάντες τῆς ἑτέρας, τῆς πανδήμου.² (185b5–185c2)

In this way, Pausanias is one of the refiners of previous ideas. Likewise, Eryximachus fails to present an entirely new approach, but rather starts where he considers Pausanias to have left off on the way to the correct theory:

Εἰπεῖν δὴ τὸν Ἐρυξίμαχον, Δοκεῖ τοίνυν μοι ἀναγκαῖον εἶναι, ἐπειδὴ Παυσανίας ὁρμήσας ἐπὶ τὸν λόγον καλῶς οὐχ ἱκανῶς ἀπετέλεσε, δεῖν ἐμὲ πειρᾶσθαι τέλος ἐπιθεῖναι τῷ λόγῳ.³ (185e6–196a2)

In the course of his analysis, Eryximachus proceeds to generalize the existing discourse to encompass wide enough a breadth so as to admit a discussion of Medicine, Music, Athletics, Agriculture, and, in fact, every other affair.

To Eryximachus, then, the two kinds of love that humans may experience in their relationships are only special cases of something much more abstract; that is, Eros is simply the thing which drives opposites to combine. And so when things at variance combine by means of the Heavenly Eros (whether they be extremes of humor, flavor, pitch or temperature, or some other continuum), the result is harmonious and orderly; whereas, when the differing things combine by means of the Common Eros, the result is of disorderliness, harm, and pestilence.

By this means, Eryximachus continues with Pausanias’s program of analyzing which kinds of inspiration are engendered by which kind of Eros, generalizing them to the point where we must understand the Inspiration introduced by Phaedrus as a special case itself of what results from, more abstractly, the joining of things together—in this case, namely, the joining of humans together.

The Novel Speeches

Aristophanes begins by noting how he intends to pursue a different tack than that those who preceded him:

Καὶ μήν, ὦ Ἐρυξίμαχε, εἰπεῖν τὸν Ἀριστοφάνη, ἄλλῃ γέ πῃ ἐν νῷ ἔχω λέγειν ἢ ᾗ σύ τε καὶ Παυσανίας εἰπέτην.⁴ (189c2–189c3)

The approach of Aristophanes is to develop his theory by providing a mythological backdrop, and then using it to explain the attractions which occur between humans. At the surface, his argument would almost appear in the class of explanations which say that different kinds of love yield different kinds of inspiration, as Pausanias argued. And yet, I think it can be shown to be not so much that, but rather something a bit different.

In enumerating the different kinds of love-pursuit that may occur (that is, men pursuing women, women pursuing men, women pursuing women, and men pursuing men), Aristophanes distinguishes between different kinds of love: when men and women pursue each other, this is the spirit of adultery; when women pursue women, this is the spirit of lesbianism; but when men pursue men, this is manliness:

ὅσοι δὲ ἄρρενος τμῆμά εἰσι, τὰ ἄρρενα διώκουσι, καὶ τέως μὲν ἂν παῖδες ὦσιν, ἅτε τεμάχια ὄντα τοῦ ἄρρενος, φιλοῦσι τοὺς ἄνδρας καὶ χαίρουσι συγκατακείμενοι καὶ συμπεπλεγμένοι τοῖς ἀνδράσι, καί εἰσιν οὗτοι βέλτιστοι τῶν παίδων καὶ μειρακίων, ἅτε ἀνδρειότατοι ὄντες φύσει.⁵ (191e1–192a2)

And so, if we wished to characterize Aristophanes’s analysis within the framework of the dual Eros, it would be the male homosexual relationships which are derived from the Heavenly Eros, and all the others from the Common one. And yet, such a characterization proves quite difficult to argue, if we consider the lines of causality between nature, love and inspiration.

Whereas we right well imagine that Pausanias would consent to the idea it is a person’s nature which determines which kind of Eros will join him to his beloved (or vice versa), and that it is this in turn which determines whether or not his inspiration is virtuous, we cannot say the same of Aristophanes.

For to Aristophanes, the nature of a human (which is to say, whether he or she derived from a man-man, a woman-woman, or a man-woman) determines which Love they will experience; this much provokes no disagreement with the previous discourse, and merely augments it with a comical just-so story. But it is not which Love they experience that inspires them with civic and virtuous concerns, but rather their nature itself:

καὶ γὰρ τελεωθέντες μόνοι ἀποβαίνουσιν εἰς τὰ πολιτικὰ ἄνδρες οἱ τοιοῦτοι. ἐπειδὰν δὲ ἀνδρωθῶσι, παιδεραστοῦσι καὶ πρὸς γάμους καὶ παιδοποιίας οὐ προσέχουσι τὸν νοῦν φύσει, ἀλλ’ ὑπὸ τοῦ νόμου ἀναγκάζονται· ἀλλ’ ἐξαρκεῖ αὐτοῖς μετ’ ἀλλήλων καταζῆν ἀγάμοις.⁶ (192a6–192b3)

It is on account of being derived from a man-man that one is daring and virile, and it is on account of being that way both that one is inclined toward homosexual love, and that one is inspired to participate in the matters of the city. So, the inspiration in Aristophanes’s framework does not derive from the Love, but rather issues directly from the primitive nature of the man himself, by which the kind of Love to be experienced is also determined.

Now then, Agathon begins by dismissing all the previous attempts at explaining Eros as missing the point, by failing to praise the god himself, but rather only congratulating the humans who are affected by him:

δοκοῦσι γάρ μοι πάντες οἱ πρόσθεν εἰρηκότες οὐ τὸν θεὸν ἐγκωμιάζειν ἀλλὰ τοὺς ἀνθρώπους εὐδαιμονίζειν τῶν ἀγαθῶν ὧν ὁ θεὸς αὐτοῖς αἴτιος· ὁποῖος δέ τις αὐτὸς ὢν ταῦτα ἐδωρήσατο, οὐδεὶς εἴρηκεν.⁷ (194e4–195a1)

The analysis provided by Agathon is, to put it briefly, that Eros alights upon those who are soft and beautiful, and that he is young and soft himself. He omits the notion of the dual Eros, and conceives that he looks for the beautiful and the good, and engenders it in everyone he touches.

Not to be outdone by Agathon, Socrates starts off by feining to have misunderstood what an encomium was, having expected to be able to simply say the most beautiful truths that could be said about the subject so well as he could, but being instead put to attribute all the greatest and most beautiful things to the subject, whether or not they are the truth.

ἐγὼ μὲν γὰρ ὑπ’ ἀβελτερίας ᾤμην δεῖν τἀληθῆ λέγειν περὶ ἑκάστου τοῦ ἐγκωμιαζομένου, καὶ τοῦτο μὲν ὑπάρχειν, ἐξ αὐτῶν δὲ τούτων τὰ κάλλιστα ἐκλεγομένους ὡς εὐπρεπέστατα τιθέναι· καὶ πάνυ δὴ μέγα ἐφρόνουν ὡς εὖ ἐρῶν, ὡς εἰδὼς τὴν ἀλήθειαν τοῦ ἐπαινεῖν ὁτιοῦν. τὸ δὲ ἄρα, ὡς ἔοικεν, οὐ τοῦτο ἦν τὸ καλῶς ἐπαινεῖν ὁτιοῦν, ἀλλὰ τὸ ὡς μέγιστα ἀνατιθέναι τῷ πράγματι καὶ ὡς κάλλιστα, ἐὰν τε ᾖ οὕτως ἔχοντα ἐάν τε μή· εἰ δὲ ψευδῆ, οὐδὲν ἄρ’ ἦν πρᾶγμα.⁸ (198d3–198e2)

After some coaxing, Socrates agrees to deliver a praise speech in the way that he sees fit, distinct from the rest. In this way, Socrates wipes clean the slate and establishes his framework as one of the novel ones. Indeed, the theory which he claims to have gotten from Diotima is more divergent from all the previous speeches than any of them differed amongst themselves.

Conclusion

As I have shown, the last three speeches were novel, in that none of them could be combined with the ones that preceded to form a non-contradictory theory of Eros. Whilst nobody should be surprised that Socrates failed to agree with anyone on something, I suggest that in addition to him, it may be no coincidence at all that it was the poets of the company, Agathon and Aristophanes, who came up with original and non-derivative speeches.