## Numbers in Agda

June 26th, 2009 by ThorstenI was talking about Li Nuo’s (our summer intern) project today. The goal is to develop a library for numbers in Agda which initially covers the integers and the rational numbers and in the long run also the Reals and the complex numbers. The goal is to establish basic algebraic properties such as that the integers are a ring and the rational numbers a field.

Instead of defining the operations on a canonical representation of numbers I suggest to define them first on a setoid and then define a normalisation operation from the setoid to the canonical representation. The laws of normalisation are the usual ones we know from the lambda calculus (e.g. look up James and my paper on big step normalisation). As I only realized after the talk it is not actually necessary to define the operation on the canonical representation – they can be simply lifted from the operation on setoids.

As we know this deosn’t work for the Reals because there is no canonical representation. A simple way to see this is to notice that all sets definable in ordinary Type Theory (w.o. quotients) have the property that if two elements are observationally equal then they are equal, where by observationally equal we mean that all functions into the booleans agree. However, this is not the case for the reals because the only functions from Real to Bool are the constant functions.

Here is the whiteboard from the talk:

numbers

## Turning amortised into worst-case

May 8th, 2009 by Nils Anders DanielssonToday I raised an open question related to my paper Lightweight Semiformal Time Complexity Analysis for Purely Functional Data Structures. The paper discusses a library/type system for Okasaki-style analysis of amortised time complexity (in a call-by-need setting). Assume that the library is used to show that a given program has a given amortised time complexity. The question is whether this program can be automatically turned into one with (nearly) the same complexity, but in a worst-case sense.

## Work stealing and implementation of runtime systems

March 16th, 2009 by GrahamPeter talked about work-stealing and implementation of runtime systems. We started with briefly discussing a simple implementation of a runtime system, and the scalability problems that you get [3]. There was a brief passage about the optimality of work stealing [1], to get straight into the new paper about the runtime support for multicore Haskell [2]. At the end we concluded with questioning the premises that seems common: each task is executed exactly once. There is a nice new paper called “Idempotent Work Stealing” [4] which changes the premise to “each task is executed at least once” and show by microbenchmarks that puts and takes executed on this queue only costs 60% of the Chase-Lev algorithm [5].

[1] Scheduling multithreaded computations by work stealing

[2] Runtime Support for Multicore Haskell

[3] Erlang Multicore

[4] Idempotent Work Stealing

[5] Dynamic Circular Work-stealing deque

## Breadth first labelling

March 6th, 2009 by GrahamI talked about Jones and Gibbons’ breadth first labelling algorithm, which uses cyclic programming:

-- Binary trees with labels in the nodes: data Tree a = Leaf | Node (Tree a) a (Tree a) -- Breadth first labelling function that works by taking a -- stream comprising the first label for each level as an -- additional argument, and returning a stream comprising -- the next label for each level as an additional result: label' :: Tree a -> [Int] -> (Tree Int, [Int]) label' Leaf ns = (Leaf, ns) label' (Node l x r) (n:ns) = (Node l' n r', n+1 : ns'') where (l',ns') = label' l ns (r',ns'') = label' r ns' -- The desired stream of labels itself can then be constructed -- by feeding the result stream back as the argument stream: label :: Tree a -> Tree Int label t = t' where (t',ns) = label' t (1:ns)

Various related topics were then discussed, including Banach’s fixed point theorem (Thorsten), the construction of final co-algebras (Thorsten), and a queue-based algorithm due to Okasaki (Nisse)

## Container eating

February 28th, 2009 by HancockI think some asked me to post a link to the slides I used

for my talk last Friday.

They’re at http://www.cs.nott.ac.uk/~pgh/cont-eating-talk.pdf

(There are some backup slides at the end I didn’t use.)

Eating: beyond streams

Abstract

`Eating’ is about writing programs that implement functions on final

coalgebras, typically stream types. The crucial thing is to do it in

a composable way, as with Unix-style piping.

I’ll quickly canter through stream eating, pointing out the use of

nested fixedpoints, and of universal properties to define things.

The main content of the talk is about eating `infinite’ objects that

inhabit the final coalgebras of container functors.

For a long time I was stuck on how to do this in a composable way;

a few days ago I cracked it, and would like to show you how.

You can regard it as a study in dependently typed programming,

in which quite a few interesting things emerge.

****

Finally, many thanks for a really fun three and a half years in

Nottingham. And for the Talisker and baccy!

xxx,

Hank

## Djinn, monotonic

February 13th, 2009 by ConorOn my way to check the plumbing, I dropped in to see how people were doing and told a bit of a story about proof search in implicational logic. You may have encountered the problem before in the context of Roy Dyckhoff’s contraction-free sequent calculi, which Lennart Augustsson turned into Djinn. Here’s a Haskell rendering of the basic idea. An implicational formula is an atom or an implication.

data Fmla = Atom Atom | Fmla :-> Fmla type Atom = String

Let’s write a checker to see if a Fmla follows from a bunch of hypotheses. Step one, introduce the hypotheses, reducing the problem to testing if an atom holds.

fmla :: [Fmla] -> Fmla -> Bool fmla hs (h :-> g) = fmla (h : hs) g fmla hs (Atom a) = atom hs a

Step two: scan the hypotheses, trying to derive the atom from each.

atom :: [Fmla] -> Atom -> Bool atom hs a = try [] hs where try js [] = False try js (h : hs) = from h a (js ++ hs) || try (h : js) hs

Step three: test whether a given hypothesis (&lsqho;in the stoup’) delivers the atom.

from :: Fmla -> Atom -> [Fmla] -> Bool from (Atom b) a hs = b == a from (g :-> h) a hs = from h a hs && fmla hs g

That’s to say, to use an implicational hypothesis, show the premise holds and use the conclusion. But from which context should we show the premise? If you look carefully, you’ll see that atom passes in the whole of its context, *bar the hypothesis in the stoup*. That stops us getting in a loop when we try to deduce A from (A → A). We haven’t thrown away any theorems, because any proof which uses the same hypothesis twice on a path in the tree can be shortened to cut out the loop.

But is that enough to ensure termination? Sure is. How might we see that? The problem is quite nasty, because if we want to show

(A → B → C) → D, A → C |- D

backchaining actually *increases* the length of the context: we end up showing

A → C, A, B |- C

but even so, you might get the feeling that the problem is getting smaller somehow. And you’d be right: we got rid of a higher-order hypothesis but acquired more at lower order. We can make that clear with a wee bit of indexing.

Here are formulae, now in Agda:

data Fmla : Nat -> Set where atom : Atom -> {n : Nat} -> Fmla n _=>_ : {n : Nat} -> Fmla n -> Fmla (suc n) -> Fmla (suc n)

The index is a loose bound on the *order* (arrow-left-nestedness) of the formula. Never use tight bounds when loose bounds will do—it’s too much hassle keeping tight bounds accurate. Now we can collect formulae in buckets according to their order. Let’s use this handy structure

Tri : (Nat -> Set) -> Nat -> Set Tri T zero = One Tri T (suc n) = T n * Tri T n

which I’ve defined recursively today for ease of iso. To see why these are sort-of triangles, instantiate T to vectors. Also T = Fin·suc goes with a bang! But I digress… Vectors can be seen as degenerate triangles.

Vec : Set -> Nat -> Set Vec X = Tri \ _ -> X

Now we can say what a bucket of formulae of a given order might be.

List : Set -> Set List X = Sig Nat (Vec X) -- Sig is the usual dependent pair type Bucket : Nat -> Set Bucket n = List (Fmla n)

And now a context is a triangle of buckets:

Ctxt : Nat -> Set Ctxt = Tri Bucket

So our checker repeatedly makes higher-order buckets smaller, at the cost of making lower-order buckets larger, but that’s a perfectly respectable way to be monotonically decreasing.

Agda’s termination checker isn’t so good at spotting that this is what’s going on, but before we had Agda’s *bag on the side*, there was a language called Epigram which resorted to Type Theory as its language for explaining termination. Gasp!

It’s gone 5pm on Friday and I’m still in school. (Thorsten and Graham are away today: they’d never allow this!) I’m just going to link to this inscrutable lump of code and finish this post later.

## Indexing a coinductive type on a trace

January 9th, 2009 by Nils Anders DanielssonConsider the following simple language, represented as a coinductive data type in Agda:

codata Expr : Set where nop : Expr → Expr send : Msg → Expr → Expr

An expression is an infinite sequence of no-ops and send instructions. Assume now that we want to index the `Expr`

type on exactly the messages being sent. One might believe that the following definition is OK:

codata Expr : Colist Msg → Set where nop : ∀ {ms} → Expr ms → Expr ms send : ∀ {ms ms′} (m : Msg) → Expr ms → ms′ ≈ m ∷ ms → Expr ms′

However, this definition has a problem; it does not actually enforce that all the messages in the index are being sent, as demonstrated by the expression `incorrect`

:

incorrect : ∀ {ms} → Expr ms incorrect ~ nop incorrect

In the meeting today we discussed various ways to address this problem.

(You may wonder why `send`

is not given the type

∀ {ms} (m : Msg) → Expr ms → Expr (m ∷ ms).

The reason is that this can make it harder to construct values in the `Expr`

family; the coinductive equality `_≈_`

is stronger than Agda’s built-in one.)

## Update on PiSigma

December 15th, 2008 by ThorstenLast Friday I gave an update on a dependently typed core language which Nicolas Oury and I are working on. We wrote a paper (you can also play with it) earlier this year which didn’t make it into ICFP and have revised the language definition considerably. Basically we got rid of some features (namely constraints) which were – in our view – to clever for a core language.

is a core language, hence the emphasis is on small leaving out lots of syntactic sugar which makes languages like Coq’s CIC, Agda, Epigram or Cayenne actually usable. The idea is that these features can be recovered by a syntactic translation (or elaboration as we say) as part of the compiler. Having a small core langauge is nice for compiler writers but also for theoretical analysis. The aim here is similar as Fc for Haskell but directed at dependent functional programming.

Unlike most of the DTP languages mentioned above, with the exception of Cayenne, is partial, i.e. programs may fail to terminate. On the other hand it is *full blown*, which means that type-checking is partial too. We think this isn’t such a big issue for **programming** if the only reason for the type checker to diverge is that you have anon-terminating expression within a type. On the other hand it is an issue for using for **verification** and it also rules out important optimisations. Hence we plan to define a total fragment but we think it is a good idea to specify the partial language first. Indeed, even when using Agda (or Epigram) we find it often more convenient to start developing in a non-total langauge and address the totality issue later (or never, depending on demand).

Here is a summary of the essential features of

- Very few type formers : types, -types , Type:Type, finite types (enumerations) as sets of labels, lifted types for recursion and coinduction.
- Depedently typed pattern matching can be derived using the primitive eliminator and equality
- Full recursion via let rec (mutual) , used to define recursive types (like Nat) and recursive values. Recursion is controlled via lifted types and boxes.
- Inductive families can be encoded using an extensional equality
- Coinductive types and families can be encoded using lifted types, overcoming some issues present in Agda and CIC

Currently we are working on a new implementation and on a revised language definition. I’ll put this up as soon as it is in a reasonable state.

## The new GHC API

December 8th, 2008 by WouterLast Friday we had Thomas Schilling visiting. He talked about his internship at MSR. He has been cleaning up the GHC API. I’ve uploaded an annotated copy of his slides.