Author Archives: austin

Have a computer monitor your code!

I’m currently setting up Hudson, a continuous integration server. Hudson helps software developers track changes to project source code. For example, say a group of developers are using a source code repository. Over time developers commit code to the repository and Hudson periodically pulls the latest project version and builds it. If everything is fine and dandy that’s great, however, if there are problems Hudson can notify developers of build errors.

In addition to verifying that a project builds Hudson is commonly used to run test scripts against projects. For instance it will run unit tests. I’m currently looking into automating code coverage generation with gcovr (a tool used in Obj-C development) and then displaying code coverage summaries with Corbertura, a Hudson plugin for displaying code coverage in an web-friendly format.

Currying Unknown Functions

Sadly, this topic confused me for awhile. Recently, I found that supporting currying for unknown functions is a fairly easy concept. I didn’t realize how easy of a concept this was until I spoke with a postdoc that has experience developing functional language compilers. 🙂 At first I was perplexed by the idea that a single pass compiler was supposed to support calling a function that may not have been defined in code. That didn’t make sense and it still doesn’t make sense! One should only be able to call a function when it has already been defined!

The only time a function may have already been defined but unknown in certain parts of code is when a function requires another function as a parameter. A generic function that takes a function as an argument doesn’t know which function is going to be passed to it… therefore we have an unknown function, inside the body of function definition.

Currying Known Functions

Currying for known functions in Blaise is now supported! Implementing this functionality wasn’t too hard. My largest obstacle was writing the proper OCaml syntax in the compiler. I understood the logic of my problem shortly after receiving my assignment but, since I’m not an avid functional programmer there were a few quirks in OCaml that I need to get used to.

Now I’m going to support currying for unknown functions. This will be a bit more difficult and I have to do a bit of research to figure out how to implement this feature.

Currying

Before last week I thought of curry as a delicious spice… from this point forward I will now think of a programming language feature. I’m currently adding support for currying in Blaise. A Blaise programmer can invoke a function with too few or too many arguments. Doing so causes a function to return a partial application instead of a value for a fully saturated function call. Later on the developer can invoke the partial application and pass the rest of necessary arguments to it. Wikipedia has a pretty good explanation on currying.

Here’s an example of currying with Ocaml-ish syntax:

let f arg1 arg2 arg3 =
    (* body of code *)
;;
let x = (f 1 2);;
let y = (x 3);;

Notice how the first time I invoke f I didn’t pass three arguments. x will become a partial application. Later, x, the partial application, is called with one argument – giving the function f a third argument it is invoked. The following line of code will result with y attaining the same value as the code above.

let y = (f 1 2 3);