Just wrote a short note about implementing resource aware domain specific languages by embedding in Idris. Still much to do, but the notation is getting better (less need to write strange looking types, for example).

We’ve finally gone all Web 2.0 in the Functional Programming group at St Andrews. Lots of us are now twittering (I’m “edwinbrady“), and we’ve started a group blog. I’ve just posted there about some Idris hacking.

I’ve been hacking merrily away in Idris over the last couple of weeks, seeing what I can make it do. One of the first things I wanted to try was an idea I had for a domain specific embedded language (DSEL) for concurrent programming. The result is written up in this draft paper.

I think one of the areas where dependently typed languages will become important, given appropriate and mature tools, will be the design and implementation of verified DSEL.
Here we use a DSEL to manage the lock state (i.e. number of times locked, type of the value stored in it) of each shared resource – it’s essentially a state monad parametrised over the type and lock status of the resources – which means that the lock state is statically known. As a result, the typechecker can verify that resources are locked before they are accessed, released before exit even in exceptional conditions, and even that they are requested in an order which guarantees deadlock freedom. Programs in the DSEL look (more or less) like monadic Haskell programs.

There is, as you would expect, an occasional need for an explicit proof term, especially to convince the typechecker that resource requests are ordered in a way which guarantees deadlock freedom. These proof terms can be computed dynamically if necessary, and we have found in practice that, when the ordering is safe, the proofs are reasonably simple. So assuming that you have put some thought into why your program is deadlock free, there should be no difficulty in proving it. I do think this is a situation where good tool support is necessary though – for the sake of the reader of the program, how do you hide the proof details so as not to obscure the algorithm, and for the sake of the programmer, how much can you automate? Can the DSEL author provide a library of lemmas and decision procedures to take the burden of proof away as far as possible? If you want complete static safety, as you probably do in a safety critical real-time system, you should expect to have to do some work to prove it, but we want to make this as painless as possible!

Any comments much appreciated!

I was at the Dependently Typed Programming ‘08 workshop a couple of weeks ago, and it was a lot of fun. Lots of interesting people were there talking variously about fun programs and implementation techniques.

One thing I thought was a little sad, though, is that we don’t yet have a real programming language (that is, a full one you can write programs in and actually run them, and interact with the outside world, read and write files, output HTML, etc, etc …, rather than proof assistants such as Coq and Agda) in which to try out the ideas for real. If you want to do that, the best you can do at the minute is Haskell with GADTs, or Tim Sheard’s Omega. These are interesting in themselves, but I want to know what we can do with full dependent types. Can we write the functional programs we know and love in the style we are used to, and add bits of dependency when we want some invariants checked, do we have to approach programming in a new way, or is some combination possible? It would be nice to have a system in which to try this out.

I’ve been working on file handling and concurrency recently, using the type system to manage state to prevent unauthorised access to resources and to ensure locks are managed correctly, even looking at how types can help prevent deadlock. I’ve been doing this in Ivor, but I think now is the time to give it a go in a real language. To this end…

…I’ve spent the last few weeks hacking on a fledgling dependently typed language called Idris.

It has full dependent types, pattern matching, and some basic IO with Haskell style do notation. I’ve tried a few simple examples, including the traditional well-typed interpreter. Types need to be given for pattern matching functions, but can often be omitted for constants – full type inference is of course impossible with full dependent types.

[Aside: An interesting thing about this is the fPlus function in the interpreter example:


fPlus : Term VNil (TyFun TyNat (TyFun TyNat TyNat));
fPlus = Lam (Lam (plusOp (Var fO) (Var (fS fO))));


This needs a type declaration because typed terms exist relative to an environement, so we have to tell the type checker the initial environment is empty. It turns out we can also just give the environment:


fPlus = Lam {G=VNil} (Lam (plusOp (Var fO) (Var (fS fO))));


So inference on terms in Idris gives type inference in the object language.]

There are a lot of theoretical issues still to sort out in dependently typed programming, such as how full dependent types interact with partial, general recursive functions, or how the universe hierarchy should be organised. I have decided (at least as far as this project goes) not to be interested in such things. I’d just like to get on with programming, and deal with such issues when the answers become more clear.

Early days yet, but I’m going to try using this for real work, and we’ll see how it goes. Any interesting updates, I’ll post them here.

Well, so much for new year resolutions . I’d like to claim I haven’t posted anything for a while because I’ve been being super-productive, but I think it’s more due to teaching and not paying much attention to blogland. Perhaps there will be more brain dumps when the students have gone…

Anyway. We’ve just submitted a paper on the carry ripple adder for binary numbers, using dependent types, to TFP 2007.

The brief summary is this: instead of writing the binary adder directly, and proving important properties such as commutativity, associativity etc directly, we write an addition function inductively over natural numbers, then the properties we care about are easy to show by induction. To write the binary adder, we construct a representation of binary numbers indexed over the natural numbers, so each binary number has an explicit decoding as a natural number visible in its type, and declare that the decoding of the addition of two binary numbers is the sum of the two decodings. If we can write such a function, we have a binary adder with all the properties of the natural number addition for free.

We’re using dependent types to give an explicit and machine checkable link between a high level implementation where correctness properties are easy to show, and a low level implementation which is something we’re more likely to want to implement in real hardware but is hard to reason about. I’m always on the lookout for more concrete problems along these lines, please let me know if you can think of others!

I’m bored, so I’m browsing the blog-o-tubes, and noticing the occasional comment wondering why functional languages like Haskell and Lisp are typically used for no more than implementing other programming languages. I won’t comment on the truth or otherwise of this claim, because I don’t think it’s a bad thing in any case. Here’s why — this is a technique I learned from Conor McBride (who learned it from his father Fred McBride), explaining how to write any computer program in two easy stages:

• Design and implement the programming language which would be best for solving the problem.
• Write the program in the language you’ve just implemented.

This may, on first hearing, seem less than helpful; sort of like telling someone that to play the guitar you just grab a guitar and move your hands around like a guitarist. But consider what is involved in implementing a non-trivial system (e.g. an AI for playing Go) — you spend some time coding up the domain knowledge (e.g. the rules of the game — this is where you design the language) and the rest of the time applying this knowledge to a specific problem (e.g. a strategy for winning the game — this is where you use the language).

I make the bold claim that most people who are faced with the task of programming a computer are not computer scientists or programmers by training, nor do they really want to know. They are perhaps physicists, engineers, mathematicians, accountants — experts in some other domain. I wouldn’t (in general, though I know several exceptions) expect them to have a deep understanding of my language of choice, Haskell, any more than they would expect me to, say, know how to design a bridge that doesn’t fall down, get an aeroplane off the ground, understand my tax return, or indeed do anything practically useful.

This is where the two stage approach to program design comes in. The programming language geek, with the help of a domain expert, designs a Domain Specific Language (DSL) for solving a certain class of problems. Then the physicists, engineers, mathematicians, accountants etc. can hack away at their own real problems blissfully unaware that they are making extensive use of laziness, monads, GADTs and so on. It’s just code reuse…

Haskell (along with other similar languages) is a particularly good language for implementing DSLs, in particular because algebraic data types allow you to express and manipulate abstract syntax easily and because Haskell makes it possible to embed DSLs as a library (Domain Specific Embedded Languages, or DSELs), thus saving you from writing a parser. Some examples which already exist are Lava (a language for describing circuit designs), Haskore (a music language) and Parsec (a language for building parsers). You could even consider Ivor a DSEL for building tactics for theorem proving. I think it’s also an area where dependently typed languages like Epigram will shine, because it will one day be possible to write verified interpreters for domain specific languages, and the users need not know anything about the details.

I don’t worry that I spend time working on languages that are primarily good for implementing other languages in. It’s these other languages that allow people to get real work done (like saving me from the wrath of the tax man), and if we write tools which make the verified implementation of these languages easier, we have done a good thing.

Greenspun’s Tenth Rule states that “Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.” I like to think this means that everyone writing in C or Fortran is following Fred McBride’s method, implementing a language then writing a program in it, whether they know it or not…

Back in the time before at Durham, we had a snazzy whiteboard on which you could press a button and get a hard copy of your scribblings. We don’t have such a thing at St Andrews, but there are two other options. One is the smart board software, where you write onto a screen then the computer then renders it illegible for you (at least it does when I try it). My preferred way, though, is one I’ve borrowed from the Epigram gang. Just take a digital photo of the whiteboard…

At the minute, we’re trying to find a typed intermediate code for representing functional programs with explicit stack bounds. Here’s what James and I came up with on Friday:

I dedided to to try out Ivor’s new pattern matching gadgetry by implementing a program I’ve been wanting to write for ages. This is a carry-ripple adder for binary numbers, where the representation of binary numbers is indexed over its meaning (i.e. the natural number it represents). Doing this has the advantage that any program written over the binary numbers must satisfy the appropriate invariant properties; a carry-ripple adder really must implement addition corresponding to addition of the natural numbers.

For reference, natural number addition is implemented as follows:

Data Nat : * = O : Nat | S : (k:Nat)Nat;

Patt plus : Nat -> Nat -> Nat =
    plus O y = k
  | plus (S k) y = S (plus k y)

A bit on its own represents either one or zero:

Data Bit : Nat -> * = On : Bit (S O) | Off : Bit O;

A number is then a sequence of binary digits where the meaning is computed in the type. Note that the bit constructor extends an n-bit representation of the number v by one bit, b, giving a new number representing 2^n*b+v:

Data Number : (len:Nat)(val:Nat)*
  = none : Number O O
  | bit : (bv:Nat)(b:Bit bv)->
          (len:Nat)(val:Nat)(num:Number len val)->
	  (Number (S len) (plus (mult (power (S (S O)) len) bv) val));

Indexing the binary representation this way means that we can give a precise specification to the add with carry function which guarantees that any well-typed function really does implement addition corresponding to addition of naturals:

Data NumCarry : (len:Nat)(val:Nat)*
  = numcarry : (cv:Nat)(carry:Bit cv)->
               (len:Nat)(val:Nat)(n:Number len val)->
               (NumCarry len (plus (mult (power (S (S O)) len) cv) val));

addNumber : (len:Nat)(cv:Nat)(carry:Bit cv)->
                          (lv:Nat)(l:Number len lv)->
                          (rv:Nat)(r:Number len rv)->
			  (NumCarry len (plus (plus lv rv) cv))

Actually getting a function which works is somewhat involved, since at each stage you need to convince the typechecker that what you’re doing is sound. The full script is available here. I think the proof script (which is doing no more than high school algebra) looks more scary than it needs to though. It’d be interesting to find a way for the machine to give more help with these.

I’m working on Ivor, a theorem proving library for Haskell. It’s an implementation of dependent type theory which is embeddable in Haskell applications and easily extensible with domain specific tactics. You can read a paper explaining the motivation and design in more detail.

I’ve been using it for research into using dependent types for proving resource bounds of functional programs, and more generally for experiments with multi-stage programming with dependent types. However, I’ve found it frustratingly hard to implement interesting dependently typed programs, because of the lack of pattern matching, or an Epigram-like elimination with a motive tactic. Doing the latter by hand is, er, an interesting challenge up to a point, but gets tedious very quickly.

And so, over the last couple of days I’ve been adding dependent pattern matching. You can now do such things as bounds safe vector lookup functions as follows:

Data Nat:* = O:Nat | S:(k:Nat)Nat; -- Natural numbers

Data Fin:(n:Nat)*
  = fz:(k:Nat)Fin (S k)
  | fs:(k:Nat)(i:Fin k)(Fin (S k)); -- Bounded natural numbers

Data Vect (A:*) : (n:Nat)*
  = nil : Vect A O
  | cons : (k:Nat)(xs:Vect A k)(Vect A (S k)); -- Bounded vector

Match lookup : (A:*)(n:Nat)(i:Fin n)(xs:Vect A n)A =
    lookup _ _ (fz _) (cons _ _ x xs) = x
  | lookup _ _ (fs n i) (cons _ n x xs) = lookup _ _ i xs;

Ivor checks that the patterns for lookup cover all possible cases (any other patterns would not be well-typed, in particular cases for vnil), and that recursive calls are well-founded.
It will, of course, only match on constructor patterns (you can’t do anything like Epigram’s views), and you can’t develop functions interactively (i.e. leave holes in terms to fill in later) but nevertheless it’s a big improvement on what was available before.

I really ought to write up the way the system works out which patterns are needed to guarantee all possibilities are covered; intuitively I’m sure it works but writing it up more formally may reveal a few holes. But it’s too late in the evening (um, early in the morning in fact) to do that just now…

I think it would be nice to deal with implicit arguments, so that you could write, e.g.:

Match lookup : (i:Fin n)(xs:Vect A n)A =
    lookup fz (cons x xs) = x
  | lookup (fs n i) (cons x xs) = lookup i xs;

Then it’s almost beginning to look like a proper programming language. However, I expect there are more important things to do first…

I like to program in Haskell, and typically write theorem provers and compilers and that sort of thing. This typically involves processing of large data structures (syntax trees representing formulas or programs) which might fail at any point. So, usually, I run such functions inside a monad; forexample, part of a typechecker might look like:

typecheck :: Monad m => RawCode -> m (Expression, Type)
typecheck (RawApply f a) =
	do (fgood, ftype) <- typecheck f
	   (agood, atype) <- typecheck a
	   if (domain ftype == atype)
		then return (Apply f a, codomain ftype)
		else fail $ "Type error " ++ ftype ++ ", " ++ atype

This way, I can call typecheck recursively on f and a and let the machine deal with what happens if there’s an error, rather than endlessly nesting case expressions.

However, the fact that fail takes a String can be somewhat limiting. What if I want to handle the error in some appropriate way which relies on me knowing the structure of ftype, for example? Or there might be some specific kinds of error I can recover from that I want to handle specially (e.g. if name lookup fails, I might want to look in some other module). I might even just want to translate error messages into a number of languages. This is the sort of thing that exception handling systems in mainstream languages can do quite easily (define an exception which carries the relevant data), but in Haskell I have to make do with a String.

The Haskell library contains an Error type, which I think would handle this sort of situation. But I don’t really like gratuitous use of non-portable features like multi-parameter type classes — I prefer to look for a simpler solution first. I like to keep things simple, so that other people can understand my code fairly easily (Six months from now, I will be one of those other people myself anyway).

[Aside: yes, I do believe Dependent Types make things simpler all round. That's a topic for another day...]

So, anyway, now I do things like this:

data Possibly a b = Success b | Failure a
   deriving (Show, Eq, Ord)

failure :: a -> Possibly a b
failure x = Failure x

success :: b -> Possibly a b
success x = Success x

instance Monad (Possibly a) where
    (Success r) >>= k = k r
    (Failure err) >>= k = Failure err
    return = Success
    fail s = error $ "Possibly definitely broken: " ++ s

Yes, it’s just like Either (but is Either a a monad? Why not? It seems to obey the monad laws; perhaps there is something I’m missing…) I like my name better for reasons you’ll see from the type of the next function. Now I can write code just like before, letting the monad deal with failure, while having more expressive errors. e.g.

data Broken = TooBig Int | TooSmall Int

doThings :: Int -> Int -> Possibly Broken Int
doThings x y = do x <- check x
                  y <- check y
                  success (x+y)

check :: Int -> Possibly Broken Int
check x | x > 5 && x < 20 = success x
        | x < 6 = failure $ TooSmall x
        | x > 19 = failure $ TooBig x

And then the calling function can handle the error in some appropriate and informative way, e.g.:

run :: Int -> Int -> Int
run x y = case doThings x y of
            Success x -> x
            Failure (TooSmall x) ->
                error $ show x ++ " needs to be at least " ++
                         show (6-x) ++ " bigger"
            Failure (TooBig x) ->
                error $ show x ++ " needs to be at least " ++
                         show (x-19) ++ " smaller"

It seems nice and simple, and a neat way of dealing with errors more nicely in a large program, so there’s probably something deeply flawed with it. Please let me know…