Using

for giving a [...]]]> As a preparation for my part of a joint tutorial Programs from proofs at MFPS 27 at the end of this month with Ulrich Berger, Monika Seisenberger, and Paulo Oliva, I’ve developed in Agda some things we’ve been doing together.

Using

• Berardi-Bezem-Coquand functional, or alternatively,
• Berger-Oliva modified bar recursion, or alternatively,
• Escardo-Oliva countable product of selection functions,

for giving a proof term for classical countable choice, we prove the classical infinite pigeonhole principle in Agda: every infinite boolean sequence has a constant infinite subsequence, where the existential quantification is classical (double negated).

As a corollary, we get the finite pigeonhole principle, using Friedman’s trick to make the existential quantifiers intuitionistic.

This we can run, and it runs fast enough. The point is to illustrate in Agda how we can get witnesses from classical proofs that use countable choice. The finite pigeonhole principle has a simple constructive proof, of course, and hence this is really for illustration only.

The main Agda files are

• InfinitePigeon
• FinitePigeon
• Examples

These are Agda files converted to html so that you can navigate them by clicking at words to go to their definitions. A zip file with all Agda files is available. Not much more information is available here.

The three little modules that implement the Berardi-Bezem-Coquand, Berger-Oliva and Escardo-Oliva functionals disable the termination checker, but no other module does. The type of these functionals in Agda is the J-shift principle, which generalizes the double-negation shift.

I am not going to explain what continuations and delimited continuations are, I will just show how to get them in eff. I should also warn you that delimited continuations confuse me deeply. The [...]]]> Let’s keep the blog rolling! Here are delimited continuations in eff, and a bunch of questions I do not know the answers to.

I am not going to explain what continuations and delimited continuations are, I will just show how to get them in eff. I should also warn you that delimited continuations confuse me deeply. The definition of reset and shift is simple:

effect reset:
  operation shift f: f (lambda x: yield x)

Reset is done with “with reset:“. Shift takes a function as a parameter and passes to it the continuation (delimited by the correspoding with). Here is a basic example:

>>> with reset:
...     shift (lambda k: k(k(k(7)))) * 2 + 1
...
63

Let’s see if we understand this. When shift hapens its continuation is “multiply by 2 and add 1″. So k will be the function $x \mapsto 2 x + 1$. Thus $k(k(k(7)))$ is $2 \cdot (2 \cdot (2 \cdot 7 +1) + 1) + 1 = 63$, if I got my arithmetic right.

They say that continuations are the GOTO statement of functional programming:

>>> (with reset: (shift (lambda k: 10)) * 3 + 1) + 2
...
12

This time when shift happens the continuation is “multiply by 3 and add 1″, so $k$ is the map $x \mapsto 3 x + 1$. But shift ignores $k$ and just passes $10$ straight to reset (that’s the GOTO), so the answer is $10 + 2 = 12$.

Let us compute the type of shift. The continuation is a function of type $A \to B$. The argument of shift is a function which accepts the continuation so it has type $(A \to B) \to C$. But this only makese sense if the result of shift is the same as the result of the continuation, therefore $C = B$. The type of shift is
$$B^{B^A} \times B^A \to B.$$
As an algebraic operation shift takes a parameter of type $B^{B^A}$, has arity $A$, and the carrier is $B$. This is a bit odd since the type of the parameter depends on the carrier and the arity. As is well known, continuations are not algebraic operations. But it seems like eff is telling us that delimited continuations are algebraic, if we look at them the right way. Indeed, consider the signature $\Sigma$ whose only operation is $\mathtt{shift}$ of type $(B^{B^A}, A)$. A $\Sigma$-algebra is a set $C$ with an operation $\mathtt{shift}_C : B^{B^A} \times C^A \to C$. Would we expect $\mathtt{shift}_C$ to satisfy any equations? By staring at the above definition of shift, we see that we should require, for all $k : A \to C$, $f : B^A \to B$ and $j : C \to B$,
$$j \circ \mathtt{shift}_C(f, k) = f( j \circ k).$$
Strictly speaking, this is not an equation in the sense of universal algebra because we used composition as well as $\mathtt{shift}_C$, whereas classical universal algebra only allows equations involving $\mathtt{shift}_C$. Nevertheless, we are still awfully close to being algebraic. Perhaps we are staring at a monad for delimited continuations? I need to think about this, or be told that someone already has. Also, what are some examples of $\Sigma$-algebras $(C, \mathtt{shift}_C)$, other than delimited continuations?

Since in eff we can have multiple instances of an effect, we get delimited continuations with multiple prompts, i.e., multiple resets. For example, try wrapping your head around the following piece of code:

>>> with io:
...     with reset as promptA:
...         print_string "Batman"
...         with reset as promptB:
...             promptB.shift (lambda k: k (k (promptA.shift (lambda l: l (k (l (k ())))))))
...             print_string "Robin"
...          print_string "Cat woman"
...
Batman
Robin
Robin
Robin
Cat woman
Robin
Robin
Robin
Cat woman
()

I have no idea what this sort of thing is good for, perhaps someone can suggest a useful program with multiple resets.

The io handler [...]]]> From some of the responses we have been getting it looks like people think that the io effect in eff is like unsafePerformIO in Haskell, namely that it causes an effect but pretends to be pure. This is not the case. Let me explain how eff handles built-in effects.

What does the io handler do?

The io handler does not print anything. It handles operations print_string, read_string, and read_string by triggering further operations, for example print_string triggers PRINT_STRING (which is not a valid operation name in eff, so programmers can’t do the same thing). Have a look at builtin.ml in the repository.

There are only a handful of such built-in operations. Currently they are RAISE, PRINT_STRING, PRINT_VALUE and READ_STRING, see the file toplevel.ml (at the moment the interpreter is a bit fishy about handling native references, but we promise to fix that soon). We try to keep their number small, as these are the gates to actual real-world effects.

Now, PRINT_STRING and the others are treated just as any other operation. Since no user-defined handler can possibly handle them (they have invalid eff names), they float up to the toplevel. The piece of theory which guarantees this is the equation which says that when $h$ does not handle the operation $f$ then $$h (f (p, k)) = f (p, h \circ k).$$

Who does all the printing then?

So what the toplevel sees is an element of the free algebra over the built-in operations. In order to do something sensible with this free algebra, eff wraps the computation in a special built-in handler that handles the built-in operations. This is the handler that triggers the actual hardware effects and yields back their results to continuations. It is the only non-pure part of eff.

The programmer cannot escape the toplevel handler, and neither can he somehow invoke it secretly to get something like unsafePerformIO. It is always wrapped around your computation, on the outside.

The only reason we could think of for having unsafePerformIO is to give the programmer a hack with which he can shoot himself in the foot. So we decided that all I/O should be handled in a tightly controlled way, just like other effects. But since we also understand that programmers need a hack that allows them to easily print debugging info (until there is a debugger), we provided the check statement for that purpose.

Can other operations float unhandled all the way to the toplevel?

Yes, this is possible when an operation escapes its handler. The easiest way to do this is to send an operation outside of its scope in a closure. For example, consider an operation kaboom:

>>> effect bomb:
...     operation kaboom(): BigExplosion
... with bomb:
...     a = 5
...     kaboom()
...     a + 4
...
BigExplosion

So far no surprises, the operation was handled. But now:

>>> f = (with bomb:
...          lambda (): kaboom ())
... f ()
...
Runtime error: Uncaught operation kaboom () (global). (L3, 1-3)

Because the operation kaboom was triggered in line 3, which is outside of the scope of its handler, it propagated to the toplevel. What is eff supposed to do with it? We decided it is best to report a runtime error. Once we have a type system, eff should be able to report at compile time that an operation might end up being unhandled.

But I want my programs to be pure!

You are out of luck then. If a program is absolutely pure, you need not run it since it won’t cause an observable effect. Even in Haskell the program is required to be in the IO monad. After all, the only way for a program to communicate with the outside world is through a computational effect.

It is a good idea to concentrate all real-world computational effects just in one place, without cheating, and treat them in the same way as user-defined effects, as far as that is feasible. It should then be possible to devise a type system which can guarantee that certain effects do not happen, just like in Haskell. The algebraic semantics of eff is such a type system, but at a semantic level. What we need now is a useful implementation of it.