Here I show how we can use Haskell’s type classes and other language features to model the Combinator Calculus. The goals of this module were:

1. don’t force any one evaluation strategy
2. allow users to define new combinators without exposing the implementation
3. allow new combinators to be defined in terms of other already-defined combinators.
4. discourage creation of non-sensical combinator expressions, or possible mis-use of the module
5. hide existential types and anything else exotic

If you want to play with it, you can do a:

$> darcs get http://coder.bsimmons.name/code/CombinatorCalculus

A Quick Combinator Calculus Primer

A Combinatory Logic expression consists of a sequence of combinator terms and sub-expressions. Combinator terms are like functions which consume some arguments (themselves combinators or sub-expressions), and return a particular re-arrangement of those arguments. When no term can consume enough arguments to be “evaluated” any further, the expression is said to be in normal form.

The SKI Combinator Calculus is a system that uses only three combinators (‘S’, ‘K’ and ‘I’) and forms a Turing Complete system. This means we can express any computation with expressions that look like SK(SSS)I(S(KS)K)I. It can even server as the basis of a turing complete programming language!

It’s a really fascinating topic, and you can get a great overview from wikipedia’s excellent Combinatory Logic article.

The Design of the Module

All terms in combinatory logic take some arguments and form a new expression from them, but different combinators transform their arguments in different ways.

We can express this in Haskell by creating a typeclass with methods that describe the behavior of a combinator. Then we can make a type (corresponding to a specific Combinator term) an instance of our class to define its behavior.

The Combinator Class

Here is how we define our Combinator class:

 -- a Class for combinators. Its methods represent a combinator's behavior on
 -- its arguments:
class (Show c)=> Combinator c where
    takesArgs :: c -> Int

    applyArgs :: c -> [Term] -> Expr
    
     -- HIDDEN METHOD: EXPORTED AS A FUNCTION:
     -- if a combinator takes 0 args, we assume it can be evaluated and we
     -- say it is not in Normal Form:
    isNormal :: c -> Bool
    isNormal = (> 0) . takesArgs
    
     -- HIDDEN METHOD: user defined combinators are placed in a black box:
    toTerm :: c -> Term
    toTerm = Term

The first two methods are the only ones exported to users of the module to define an instance of Combinator. takesArgs is used to indicate how many arguments this particular combinator requires before it can be evaluated.

applyArgs actually performs the transformation of those arguments; it is given a list of terms (of length equal to `takesArgs`) and returns a new expression (type Expr).

The third method is used to check if an expression is in normal form. It is exported as a regular function, meaning that users can use it in their code but cannot use it in their own instance declarations. Instead the default value would apply.

The fourth method `toTerm` is used internally to encapsulate some Combinator class item in a `Term` data type. We use this when composing combinator expressions, in order to preserve the tree structure of the expression. (see below for more on this)

The Term and Expr types

The module defines two new datatypes, both of which are instances of `Combinator`.

`Expr` is a newtype wrapper around Seq Term, but we don’t export the implementation so we can change this if we don’t want to use Sequences:

newtype Expr = Expr { combSeq :: Seq Term }

It simply represents a CL expression as a sequence of terms. Making it an instance of `Combinator` expresses the notion that an expression can be thought of as a combinator term whenever the need arises. In fact the distinction is simply one of evaluation strategy.

`Term` is a wrapper for Combinator terms and sub-expressions. It is mutually-recursive with `Expr` and the two together form the tree structure of a combinator expression:

data Term = forall c. Combinator c => Term { unbox :: c }
          | SubExpr   { subExpr :: Expr }
          | NamedExpr { subExpr :: Expr,
                        name    :: String }

All three constructors are hidden from the user. `SubExpr` simply holds an `Expr` type and represents a parenthesized sub-expression within the top level combinator sequence. `NamedExpr` is identical except that it also contains a String, which will be returned when `show` is called on that constructor. Here is the `Show` instance for `Term`:

instance Show Term where
    show (NamedExpr _ n) = n
    show (SubExpr e)     = "("++ show e ++")"
    show (Term t)        = show t

The remaining constructor is the most interesting: the `Term` constructor houses an existentially-quantified type and can hold any type value of the `Combinator` class.

Notice that the type variable does not appear on the left side of the = in the type declaration. What this means in practical terms is that the `Term` constructor becomes a “black box”; once a value is inside, the only things we can “do with it” are to apply polymorphic Combinator class functions and methods.

And that’s why we have the internal `toTerm` method; it allows us to wrap sub-expressions in the `SubExpr` constructor, preserving the tree structure of an expression as we compose it. Without it we would either need to export multiple functions for composing a term with an expression, an expression with an expression, a term with a term, and an expression with a term. Ugly!

Exported functions

Our types and classes allow us to do some neat stuff. As mentioned above, we can compose expressions using a single haskell infix function. Since all the nice ASCII combinators were taken (and since I’m the only one using this) I decided to go with a Unicode symbol, the middle dot, for composition:

 -- operator for composing combinator expressions. This is the Middle Dot,
 -- unicode character 00B7. It is easily inserted in vim using the digraph:
 --       Ctrl-K '.' 'M'
infixl 7 ·

…and the implementation:

 -- for composing Combinator expressions:
(·) :: (Combinator c1,Combinator c2)=> c1 -> c2 -> Expr
c1 · (toTerm->t2) = 
     case toTerm c1 of                                                                
          (SubExpr e) -> e `appendTerms` singleton t2                                
           -- named expression or bare Term start a new sub-expression:              
          t1          -> Expr (singleton t1 |> t2)

We also have the ability to define new combinators in terms of other combinators using the `named` function. Here is an example showing how `I` can be defined in terms of `S` and `K` and used to form a Combinator Calculus equivalent of the Church Numeral 2:

60 two = S·(S·(K·S)·K)·cI
61     where cI = (S · K · K)  `named` "I"

Playing with it

The evaluation function exported in the module was written fairly hastily, but it is good enough to let us play with evaluating expressions.

I’ve run out of time on this post, but you can grab the darcs repo above and run the ‘main’ function in `Examples.hs` and check out the source for more info. I’ll maybe show some cool examples in a later post.

Thanks for reading!

Note: this is part of a series of posts is related to the “17×17 Challenge” posted by Bill Gasarch. The goal is to color cells of a 17 by 17 grid, using only four colors, such that no rectangle is formed from four cells of the same color.

In my last post, I gave a symmetrical rotation of the known 74-cell single-coloring. I want to use a slight variation of that grid to show why I think treating the grids as symmetrical will help us in solving this problem.

Here is a new spreadsheet, with several panes you can click through on the bottom. Panes ONE through FIVE represent the first few rows of a single-coloring in which we avoid making any real choices, thanks to a few assumptions we make (I’ll come back to that).

Orange represents the row we’re coloring, gray cells are rectangle forming cells (in which marks are not allowed), and blue cells represent what I consider to be the real search-space:

NOTE: We’re simply using another automorphism of the original 74-coloring, i.e. a series of rotations that preserve all the significant attributes of the graph.

Making Coloring Decisions

We can choose, arbitrarily, to start with a 5-cell row starting on the cell in the upper left. This is our first decision: if it were that in an optimal single-coloring of 17×17 no row with five colored cells shared a cell with any column with five colored cells, then we would have made a poor decision.

But given that in the 74-coloring that we have, all 5-colored-cell rows share a cell with a 5-colored column, we can probably assume that at least one will in our optimal single-coloring. So our first row (in pane 1) is a non-decision.

We continue with the second row by dumping 3 cells as soon as we can (i.e. as far to the left as possible. The only decision made here is in whether to make row two a row of four or five. But as we can see very quickly (and as a shallow search algorithm would see very quickly), making row 2 a five-colored-cell row would force us into forming a 3-cell row out of row five.

So in row 2 we have an easy decision (seeing that we would soon regret creating a 5-cell row) based on our assumption that a good singly-colored grid will have its cells spread evenly over rows & columns.

And we have the non-decision of the column placement of those three cells: because identical columns (in this case empty columns) can be freely swapped without changing anything, there is no need to try every combination of column placement for the row. We put off our decision making for later.

We continue on in the same way.

Search Ideas

I’m coding up a program to try to generate good grids based on some heuristics. I think that a minimax type solution might be good: in which the coloring of a cell is assigned a point-value based on how many future cells it makes unusable. I could then keep track of which previous cells were complicit in forming potential rectangles and back-track at apparently-bad decisions: i.e. hill climbing.

I may try to formulate the algorithm like a game and see if I can use the game-tree module by Colin Adams.

Conclusion

It seems to me that the key to the problem of a single-coloring is shrinking the search-space by eliminating false-choices. Treating the graph as it’s symmetrical (by our definition of symmetrical) automorphism is one way: suddenly the search space becomes the shaded area in the graph above.

Thankfully, my next post will be haskell-related and have nothing to do with Grids.

Single-Color Subsets

I’ve started by trying to find an algorithm to find optimal single-color subsets, i.e. a way of coloring a grid with one color such that no rectangle is formed by the colored cells, and we have the greatest number of cells colored as possible. I started thinking of coloring cells one at a time, following a path based on the notion of an “extended rectangle” where the fourth side was longer or shorter than the first, to avoid forming rectangles.

I also noticed that we could traverse all the cells in the largest known 17×17 subset by following a simple spiraling algorithm. It didn’t seem to matter which cell or direction we started in either:

go until you hit a colored cell, then rotate 90 degrees

Optimal Grids

I generated some optimally-colored grids to see if they all followed this property of being traversable via this “rotation” algorithm above. It turns out that some directions and starting points loop before they touch every colored cell. I suspect that will also be the case for the 74-color grid above.

Here are the grids I was able to generate via brute force:

Notice that, as you might guess, colored cells are spread out as evenly as possible among rows and columns (i.e. no two rows differ by more than one in their number of colored cells).

…and Symmetry and Rotations

Also notice the diagonal symmetry that all of the grids exhibit. The 5×5 grid was not symmetrical when it came out of my brute force algorithm, but I was happy to see that I could turn it into the above symmetrical version with a few rotations (a fun puzzle by the way). The symmetry reminds me of creating/solving sudoku and I wonder if this is a similar constraint-solving problem.

It would be interesting to see if the 17×17 grid was symmetrical in one of its possible rotations. I would like to look into that as well as code up a symmetrical variation of the algorithm I described in my last post. If all optimal subsets were symmetrical, that could make the search-space considerably smaller.

I also wonder whether all subsets of the same size are not simply rotations of the others. This seems to be the case for the smaller optimal subsets in the image above.

Four-Coloring the 17×17 Grid

The author suggests that a 17×17 grid is an edge case, meaning that it may or may not be possible to four-color. A single-coloring of at least 73 must be possible in order for a four-coloring to be possible: 73 + 72 + 72 + 72 = 289 = 17 x 17. The author of the challenge has found one of size 74.

Given the difficulty of finding a single-coloring (74 colors seems to be the largest known), we can perhaps assume that each of the four single-color subsets will be evenly distributed with 4 or 5 cells per row/column.

Thus every row of a successful four coloring will have 4 + 4 + 4 + 5 = 17 in each of the four colors respectively.

There are 2380 possible unique 17-length rows with four colored cells in the row. There are 6188 with 5 colored. Here’s the code I used for that fun fact:

-- finding promising rows:
allRowsSize sz n
    | sz == n = [ replicate n  True ]
    | n  == 0 = [ replicate sz False ]
    | otherwise =
       [ True:as  | as <- allRowsSize (sz-1) (n-1) ] 
        ++ [ False:as | as <- allRowsSize (sz-1) n ]

Going Forward

If the couple ideas I still have for an optimal single-coloring don’t work out, it may be interesting to try to “deconstruct” the known 74-coloring, treating it like the algorithm I developed in my last post, but in reverse, noticing the “choices” made.

After giving up on a deterministic single-coloring algorithm it might be interesting to investigate some kind of ladder climbing algorithm that looks at trying to consolidate rectangle-forming squares.

Finally, an approach that might have been the easiest all along, would be to take the author’s 74-coloring above and try to generate 4 different permutations of sizes 73 and 72 that could fit together. We don’t learn too much from that though.

I’m really interested to know your thoughts on the problem as well. So leave a comment if you like!