IoC simply refers to a library passing control to it’s caller.  A typical object-oriented implementation would be a function which takes an object that implements ISomething where ISomething has a single method that the function then calls.  Those familiar with the visitor pattern should recognize that the visitor pattern is just a specialization of IoC where the callers code is applied to each object in a collection (actually any structure, it doesn’t *have* to be a collection).

I think the tie between IoC and functional programming should be pretty obvious at this point.  If your language supports first class functions and closures, then creating an interface with a single method is just extra work when you can simply pass a function as a parameter.   In fact, since a closure will close over lexical variables to maintain their “state”, both types of IoC implementation (Interfaces and Functions) are exactly equivelant in terms of power.  I believe that using a simple function is more readable though, and it’s certainly more convienent for the caller to not have to create a class that implements ISomething.

The tie between DSLs and IoC is more abstract and requires exploration into the problems being solved.  IoC is a useful design when the problem is not completely specified.  If you are writing a library and the only thing that will vary in how it’s used is the inputs, IoC is just extra typing with no real benefit.  If your problem is only partially specified on the other hand, then IoC allows you to implement the bits of the solution that you can infer from the specs, and leave the rest up to the caller.  This is why very generic libraries tend to use IoC a lot.  A DSL typically provides the users with a base set of combinators (functions that create functions out of other functions) to build up functions that perform a specific type of task in a very high level manner.  A DSL for writing parsers should look very close to BNF so that a grammar can be encoded in the host language with as few implementation specific details as possible.  How to do this with combinators is an interesting topic itself that deserves it’s own post and maybe I will get motivated and write one some day.  A more intuitive example is configuration files, any time you have a configuration file that can change the flow of a program you are creating a mini-language and you are passing control to the end-user (ie.. IoC).

So great, they are the same thing conceptually, what do we gain from this?  Well we can transfer the knowledge we have from one paradigm (like OO) to another (like functional) and vice versa.  More concretely, by recognizing that they are all ways to partially specify a solution, we now have a good solid concrete criteria for deciding when one of these types of implementation are necessary.

On a side note, this should help highlight the difference between a pattern and an implementation.  Interfaces/Functions/Monads are ways to implement the IoC pattern.  Creating a library to “handle IoC” is confusing the two, and if you find yourself writing or consuming one of these libraries, then some reflection on how your handling the task at hand would probably do some good.

1. You always have a full copy of the repository with all the meta-data, online or off
2. You can merge with anybody’s repository, not only a single central server
3. Even with the full history, git repositories take less space than a SVN checkout

   brandon@Brandon:~/localtmp/clone$ du -sh *
   1.6G    cohiba.git
   2.6G    cohiba.svn

4. Modifying the history is easy, using git rebase -i <some_revision> will bring up a list of patches in your favorite editor and allow you to merge/reorder/delete them, then it will apply them as you’ve specified, re-committing with each one

   pick e4eb2ca Added -d option to only look at 1 date
   pick 881ef7f Fixed bug that caused an Prelude.head: empty list exception if no work orders were pushed
   pick 3595183 Added line itemized reports on pushed work orders
   pick 1b6ff52 Fixed the parser so that it doesn't break if there is a [] in the stack trace It was using a bit of a hack, but i've cleaned up the parser so there should be no more suprises, no matter what we throw at it
   pick 12b7023 Changed slurp_until to fail on eof
   pick e511b15 New log file for tests
   
   # Rebase 378dd8b..e511b15 onto 378dd8b
   #
   # Commands:
   #  p, pick = use commit
   #  e, edit = use commit, but stop for amending
   #  s, squash = use commit, but meld into previous commit
   #
   # If you remove a line here THAT COMMIT WILL BE LOST.
   # However, if you remove everything, the rebase will be aborted.

5. You don’t need a centralized server with a single ‘master’ copy of the codebase with git, but that is  still how most software shops will operate.  Any mucking with this master copy would be noticed by all because git revision id’s are hash sums of the entire history up to that point.

I created a git repot on github.com. Tarballs/zip files can be downloaded here. Or if you have git installed you can run:

git clone git://github.com/bniemczyk/bnirc.git

If your interested in helping test please do! Make sure that the python and ncurses header files (python-dev and ncurses-dev on debian) are installed before you run ./configure, or you’ll get a very bare-bones interface that is really only meant for debugging.

In order for -Calculus to be useful, we have to be able to encode data. In our previous post we used integers and booleans without any explanation as to how they may be encoded. This picks up and fills out those details.

Booleans

It is useful to encode boolean values as functions that take 2 parameters and then evalute the correct argument.

Assuming we have a boolean we can encode an if-then-else function as where is the result if and is the result if ie..

Church Numerals

…

And now to show the basic operations on numerals

Increment

Example :

Decrement

Example:

Addition

Example:

We can show that

Multiplication

Example:

In this post and all the following posts I write, all -calculus expressions are left-associative, ie..

In this post I will expound upon some of the things I glossed over in the last post.

Variable Bindings

The operator binds a variable. If a variable occurs in the body of an abstraction but is not bound, then it is called free. In the case of name clashes, variable is bound to the inner most .

-conversion

The easiest way to ensure that variable names don’t have scope issues is to simply rename all bound variables to a unique name:

-reduction

What I referred to as simplifying in the last post was actually a -reduction. -reduction is the act of making all the applications in an expression that do not use any bound variables. If all bound variables in expression have unique names, then a beta-reduction is very simple:

reduces to

The -conversion described above is very important because if variable names clash, then a -reduction is much more complicated. Take the following term:

Without first applying an -conversion we might end up with something like this:

wrong:

Now our free variable in is incorrectly bound. Instead we should get this:

correct:

Now our newly renamed is still a free variable.

That’s it for this post, in an upcoming post I will explain how to encode some basic datatypes using pure -calculus.

Why?

-Calculus is important because it has a close tie with functional programming.  In fact most functional languages compile to some form of -Calculus.  You could say that -Calculus is to functional programming what the Turing machine is to imperative programming.

The very basics

Everything is a function in -Calculus but for the purposes of this post we will extend the core calculus with integers and basic integer operations.  In a future post we will go into how integers can be represented as functions (for those unwilling to wait, check out Church Numerals).

Lets start with a sample expression:

This is called an abstraction.  In this expression we call the x variable bound and the y variable free.  There is one other operation called application.  Application takes the form of:

-Calculus evaluates expressions by simple substitution so the above expression simplifies to .  One thing to note about this is that in the term where is another term, only free occurences of get replaced.

therefore simplifies to .

All functions are functions of one variable

-Calculus does not allow abstractions that take multiple arguments.  Instead you write functions that return functions which take the next variable.

simplifying this with we get:

For conciseness, can be written as but it is important to remember that this is a function that takes the value for x and returns a new function.

The Y combinator

It may have occured to you that recursion cannot be implemented with a simple substitution model and there are no looping constructs.  How can this be Turing Complete?  Recursion can be simulated by using a function such that (ie. a fixed-point function), assume for the moment that such a function exists.

If you wanted to represent the factorial function with recursion you could do it as:

Since terms are not named, and recursion is impossible, we have to write a function that takes (Yf) as a parameter.

we’ll call this expression for brevity.

Since:

and f is bound to giving us recursion!

Now to show the (not-so-magical) fixed point function :

Proof

Update:
After enabling TaintIn for some of my code, DBI became even more retarded. With TaintIn DBI also checks if your sql parameters are tainted. So some code like $sth = $dbh->prepare(“insert into mytable values (?)”); $sth->execute($user_supplied_data); fails. In my opinion this defeats the entire purpose of DBI parameters. I may patch DBI locally and see if I can get it applied upstream.