Tuesday, March 12, 2013

Computing trending at Kent

I was lucky enough to go to two quite different events at Kent today that would have been inconceivable just two years ago. This morning I spent time at the #kenthack and this afternoon at a Digital Humanities event … quite different, but both lots of fun.

The #kenthack was the brainchild of some computer science students, getting together collectively to hack out some new ideas, sustained by a heady mixture of sugar, saturated fats and salt (OK, sweets and doritos).
Nice ideas going around included a version of the old "helicopters" game, with a motion sensitive interface. Sorry I don't remember the name of the particular piece of kit, which is able to sense all 10 fingers and thumbs, up to about 50cm away, based on 3 IR sensors and an ARM chip. More info about the outcomes at www.kenthack.com. Great atmosphere, and refreshing to see people getting together to have fun coding.

This afternoon to the new "crit space" in the school of architecture for a digital humanities event, bringing together academics from architecture, history, english, archaeology, film studies, linguistics to talk about their research and teaching activities informed and and mediated by digital technologies.

Exciting to hear about what's going on. Highlights included

  • using network visualisation of word counts and proximities to understand documents;
  • how software has revolutionised the practice of linguistic analysis of real speech, and the repercussions for speech therapy;
  • understanding the mental mapping and conceptualisation of space, time and software behaviour in game development software.
The talks were good, but as always, discussions over coffee were more fruitful. I hope we'll be able to build some links with the last project … exciting things to do with new APIs, and also with data mining of "big data" from programmers of different kinds. Also able to catch up with learning support staff from UELT to share our enthusiasm for panopto, but at the same time to bemoan the fact that we're unable to share any of our exciting teaching and learning initiatives and materials outside the university. Grr.

Wednesday, March 6, 2013

Commercial users of functional programming: call for tutorials

Commercial Users of Functional Programming (CUFP) is an annual meeting co-located with the International Conference on Functional Programming which this year will take place in Boston, MA, USA on 22-24 September 2013. CUFP aims to bridge the gap between academia and users applying functional programming in practice. CUFP provides high-quality practical tutorials covering state-of-the-art techniques and tools for functional programming.

We are seeking proposals for half-day tutorials to be presented during the first two days of the meeting, 22 and 23 September, with the main CUFP session on 24 September.

Among the suggested topics for tutorials are:

- Introductions to functional programming languages: in the past we have had introductions to Clojure, Erlang, F#, Haskell, ML, OCaml, Scala, Scheme and others.

- Applying functional programming in particular areas, including the web, high-performance computing, finance.

- Tools and techniques supporting state of the art functional programming.

Tutorial proposals should address the following points

- Title
- Abstract (about 100 words)
- Goals: by the end of this tutorial you will be able to …
- Intended audience: e.g. beginners, those with a working knowledge of X, …
- Infrastructure required: For example,
    - will participants need access to a particular system?
    - can they be expected to have this on a laptop, or does it need to be provided by the meeting?

and should be sent by email to

- Francesco Cesarini: francesco@erlang-solutions.com
- Simon Thompson: S.J.Thompson@kent.ac.uk

by 31 March 2013.

Tuesday, February 19, 2013

Evaluating, compiling and running arithmetical expressions.

Partly reminded to do this by recent FB posts by Graham Hutton and Andy Gill, I used foils and OHP pens to deliver my last lecture in the functional programming course "live". I like the sense of tension you get from writing stuff "out there" and interacting with the class in a more thoroughgoing way than seems to happen with pre-prepared slides.

What did I cover? The aim was to hammer home the message about the data driving the programming, and I took the example of processing arithmetical expressions, writing an evaluator, a virtual machine and a compiler … I didn't cover parsing, but that can come in the second half of the course: Stefan?

So, we started with a data type for expressions, with literals, +, - and *.

data Exp = Lit Int 
         | Add Exp Exp
         | Sub Exp Exp
         | Mul Exp Exp
          deriving (Show)

with the expression 2+((3-(-3))*3) represented by

(Lit 2) `Add` (((Lit 3) `Sub` (Lit (-3))) `Mul` (Lit 3))

The first thing to define is the evaluator, which has a straightforward data-directed definition:


eval :: Exp -> Int

eval (Lit n)       = n
eval (Add ex1 ex2) = eval ex1 + eval ex2
eval (Sub ex1 ex2) = eval ex1 - eval ex2
eval (Mul ex1 ex2) = eval ex1 * eval ex2


What sort of machine should we use to evaluate the expressions? The simplest approach is to build a stack machine, which can either push literals, or apply an operation to the top elements on the stack (from my slides):

Here's the type of code.

data Code = PushLit Int
          | DoAdd
          | DoSub
          | DoMul
            deriving (Show)


We can describe this machine by giving the function that runs a program, when we represent the stack by a list of integers, and the program by a list of code.

type Program = [Code]
type Stack = [Int]

run :: Program -> Stack -> Stack

run [] stack 
        = stack
run (PushLit int : program) stack 
        = run program (int : stack)
run (DoAdd : program) (v1:v2:stack)
        = run program (v1 + v2 : stack)
run (DoSub : program) (v1:v2:stack)
        = run program (v1 - v2 : stack)
run (DoMul : program) (v1:v2:stack)
        = run program (v1 * v2 : stack)
run _ _ = []


An alternative here would be to give the oneStep function, and then to define run in terms of that: that's an exercise for the reader.

The final piece of the puzzle is to define the compiler:


compile :: Exp -> Program

compile (Lit n) 
        = [PushLit n]
compile (Add ex1 ex2)
        = compile ex2 ++ compile ex1 ++ [DoAdd]
compile (Sub ex1 ex2)
        = compile ex2 ++ compile ex1 ++ [DoSub]
compile (Mul ex1 ex2)
        = compile ex2 ++ compile ex1 ++ [DoMul]


VoilĂ !

Why do I like this example so much?

  • It shows Haskell's strengths: I think my students get fed up of me comparing Haskell with Java, but this is a case where it really shines. The types make it very clear what's going on; the algebraic types guide the definitions, and we can even prove it correct …
  • What is the statement of correctness? That evaluation is the same as compiling and running:
    run (compile exp) [] = [eval exp]
    but there's a bit of work to do to get the right induction hypothesis (exercise).
  • There are lots of nice generalisations: we can introduce local definitions with a let construct, or indeed allow (updatable) variables within expressions. All these can be added in a nice type-directed way.
  • There are lots of related exercises too: e.g. generate truth tables for Boolean expressions, and using these write tautology checkers.

So, a very enjoyable last lecture on Haskell.

Tuesday, February 12, 2013

Teaching Haskell … but for the last time for a while.

For one reason or another, I haven't been teaching functional programming at Kent for a few years, so it's interesting to be back doing it, and to reflect on that.

The last time I was involved was when we were teaching Haskell in the first year, starting in the second term, and following up on Java which had been taught from the start. We came to the conclusion that this wasn't ideal: instead of reinforcing each other, it seemed perverse to start with a second paradigm before the first one was properly internalised. This time I'm teaching in the second term of the second year … just like we did twenty years ago, in fact … and it seems to be going much better.

One thing that's really helpful is to be able to discuss features of Haskell using Java as a reference point.   For example, what does it mean to belong to a class? Well, you have to implement the interface that's given by the class declaration. Seems to demystify the idea.

Sometimes Haskell is so much better: data types with multiple constructors (e.g simple geometric shapes such as circles and rectangles) just work in Haskell. No ugly abstract base classes and subtyping, no problem with binary methods, the joys of pattern matching … great stuff.

Types play an important role: the first and most important piece of documentation for any function, but also a way of discovering things in the library thanks to hoogle. If you've not tried this out, give it a go: it works for monotypes, such as Char -> Bool, just as much as for complicated polymorphic examples. Really useful, and appreciated by the students.

On the other hand, some things are difficult for the beginner. It's too easy to overlook concrete syntax when you understand it well - indeed the whole point is that the syntax almost disappears, and you perceive the intention, or the semantics immediately - but that's just not the case for beginners, and the novelty of the Haskell syntax can be a problem. Just function application looks unfamiliar, and the layout sensitivity can trip people up too. Other little irritations: length (of a list) returns a fixed size Int, as does replicate: we should probably use the generic versions from scratch and ignore Int altogether?

Funny things you wouldn't think of. A colleague sitting in on the lectures noted that the (x:xs) notation could be a problem: sometimes it wasn't clear when I was saying "x is" and when I was saying "exes". Perhaps I need to say "excess" instead, or maybe ditch that notation altogether?

I've been lucky enough to have inherited Olaf Chitil's slides (though I think some of my DNA is in there from a number of generations back) which are great. The problem is I'm never happy with using someone else's slides - or indeed my own from a previous year - so start rewriting them. Even when this is the last time they will be used, because next year we're trying something different …

As a root and branch curriculum review we looked at what we taught in the second year of our programmes as core material, and found that we wanted to include about 180 credits worth of material in a 120 credit year. Together with all the other material we saw as core, we wanted to carry on teaching functional programming, and also to teach concurrency (which we currently do in occam-pi, optionally to second and final years), but we didn't have enough time to teach two separate languages. So, we decided to use a language with both: that could be Clojure, we could look at Haskell's various concurrency extensions, but we'll be working with Erlang next year.

Not everyone was happy with this … indeed I'm not 100% sure … but it will be really interesting to look at Erlang as a practical functional/concurrent language, and use it as a base for exercises and projects, as well as a comparison point for other approaches like Haskell, occam-pi. I'll report back in a year's time …

Back on track in the blogosphere

Back again to my blog after about 6 weeks off. What was the problem? It wasn't that I didn't have anything to say, because lots of things were going on: teaching a functional programming (Haskell) undergrad course for the first time in ages, convening a module for new lecturers at Kent on developing as a researcher, doing project work on both Release and PROWESS, as well as getting to some films, concerts and so on. I'll be blogging about some of these in the next few days, I hope.

No, I think the problem was that I didn't have enough train journeys to go on. Somehow the ambiance and length of a train journey is just right for getting thoughts marshalled and into blogger. As you might guess, I'm writing this on the train: en route to Swindon for a two day grant review panel at EPSRC. There certainly should be another post in a couple of day's time, on my way home, if not before …

Wednesday, December 12, 2012

What makes a good plan?

Having spent quite a bit of last weekend having to write a research plan, I've gone back to the question of “what makes a good plan?”. I think there are two principles that identify the best plans … I wonder how well mine measures up?
  • You should be able to summarise it on the back of a postcard, or in a 30 second soundbite. That probably means that there are three or four key points, rather than thirteen or fourteen, or even thirty or forty.
  • The real decisions in the plan are those whose negation would be a sensible choice. So, saying that we choose to do the best possible research, or that we aim to publish in the highest quality journals, are pretty much content free … what plan would aim not to do those things?
So, how would I summarise the research plan in three points?
  • Aim to increase research funding by 30% over three years … a modest aim, but one where we could perfectly well fail if we didn't work to achieve it.
  • Set up a formal industrial panel … in the last decade or so we've dealt with industrial input on an ad hoc basis (apart from the Kent IT Clinic advisory group) … it's time to try to get more synergy with a group of stakeholders: industrialists, educators and alumni.
  • Make sure that we have enough space to house researchers, equipment and so on … this is a real problem at our Medway campus, and will harm our research unless we're able to get the space. [This is plan as negotiating tool I suppose.]
What about the negation test? Well - sadly - I've failed that a few times: “highest quality venues”, “widest possible dissemination”, etc, but at least there are some places, and particularly those mentioned in the three points above, where we're making a definite commitment to doing something rather than something else. Whether or not we're ultimately successful is something I can come back to in 2015 …

Friday, December 7, 2012

Links to make you think, part 2

In my first post on this blog I posted a list of links to twitter posts for the People and Computers course, chosen to give a context to studying computer science.

Here's the second (and final) collection of tweets, in chronological order:


Sixth week



Seventh week



Eighth week



Ninth week



Tenth week



Eleventh week