Comments on: Seemingly impossible functional programs

By: Martin Escardo

Martin Escardo — Wed, 16 Dec 2009 09:29:35 +0000

The promised follow-up blog post hasn’t been written, although there is a related one at

http://math.andrej.com/2008/11/21/a-haskell-monad-for-infinite-search-in-finite-time/

There are, however, a couple of papers that develop/apply these ideas, available from my web page, written after this post:

1. Exhaustible sets in higher-type computation
2. (With P. Oliva) Selection functions, bar recursion, and backward induction.
3. Semi-decidability of may, must and probabilistic testing in a higher-type setting.
4. Computability of continuous solutions of higher-type equations.

By: Jason Orendorff

Jason Orendorff — Wed, 09 Dec 2009 18:06:24 +0000

Martin, this whole post was fascinating but even so those last two sentences pack the biggest punch of all. Where should I look for the follow-up?

By: A Rant A Day - The Power of The Functional or: I’ll bet you can’t do this in Java

Wed, 10 Dec 2008 02:53:49 +0000

[...] With Lazy Evaluation, an expression isn’t evaluated as soon as it is created; instead it is delayed until that expression’s value is needed. One of the neat tricks provided by lazy evaluation is the ability to work with infinite sets – for example, you can literally have a variable which holds all the natural numbers, all the primes, or all the Fibonacci numbers. This sometimes provides rather surprising results – such as the ability to exhaustively search over infinite spaces. [...]

By: What do We Have to Know About a Function in Order to Compute its Definite Integral? « XOR’s Hammer

Thu, 21 Aug 2008 04:54:50 +0000

[...] Actually this algorithm doesn’t quite work, as there are some a couple of details that I’ve omitted, but it is essentially correct. For more information, see Alex Simpson’s paper, and for more on Berger’s work, see Martin Escardó’s blog post. [...]

By: Martin Escardó

Martin Escardó — Mon, 01 Oct 2007 14:28:45 +0000

I've found a way of making the fastest algorithm about 40 faster by avoiding the trees and instead treating functions as trees:

> find = find_viii
> findBit :: (Bit -> Bool) -> Bit
> findBit p = if p Zero then Zero else One
> branch :: Bit -> Cantor -> Cantor -> Cantor
> branch x l r n |  n == 0    = x
>                    |  odd n     = l ((n-1) `div` 2)
>                    |  otherwise = r ((n-2) `div` 2)
> find_viii :: (Cantor -> Bool) -> Cantor
> find_viii p = branch x l r
>  where x = findBit(\x -> forsome(\l -> forsome(\r -> p(branch x l r))))
>          l = find_viii(\l -> forsome(\r -> p(branch x l r)))
>          r = find_viii(\r -> p(branch x l r))

This doesn't need the memoization, because the things one needs to remember are bound to variables in the where-clause. Using this algorithm, comparing f' and g', and f' and h' for equality moves from 6.75 and 3.20 seconds to respectively 0.14 and 0.09 seconds (using the Glasgow interpreter in all cases).