Hume

Hume is what happens when functional programmers take hard real-time seriously. Designed from 2000 onwards by Kevin Hammond at the University of St Andrews and Greg Michaelson at Heriot-Watt University, it is named for the 18th-century Scottish philosopher David Hume - fitting for a language built in Edinburgh’s and St Andrews’ academic orbit - with the engineer’s backronym Higher-order Unified Meta-Environment attached for good measure.

The problem Hume attacked is easy to state and brutally hard to solve. Languages like Haskell offer higher-order functions, polymorphic types, pattern matching and automatic memory management - but with essentially no way to promise how much memory or time a program will use. Embedded and safety-critical systems demand exactly those promises. Hume’s wager was that you could keep the abstraction and the guarantees, if you designed the language around cost modelling from day one.

History and origins

Hume first appeared in July 2000, in a paper titled “Hume: a Functionally Inspired Language for Safety-Critical Systems” at the 2nd Scottish Functional Programming Workshop in St Andrews, followed within months by “The Dynamic Properties of Hume” at the IFL 2000 workshop in Aachen. Both authors came from the functional-programming research community - Hammond had been deeply involved in Haskell implementation work - and the language wears that heritage openly: its expression language reads like Haskell.

But Hume was never a general-purpose Haskell competitor. Its stated purpose was to explore what the designers called the expressibility/costability spectrum: how much expressive power a language can offer while its space and time behaviour remains statically analysable. That framing - treating decidable cost analysis as a first-class design constraint, on equal footing with type safety - is Hume’s signature idea.

Design: boxes, wires, and two languages in one

A Hume program is built from boxes - concurrent processes that never terminate. Each box repeatedly pattern-matches on its inputs and generates outputs, which travel along asynchronous wires to other boxes or to streams connected to devices. The result is a layered design:

• an outer declaration and metaprogramming layer,
• a coordination layer describing the network of boxes, wires, streams and devices - essentially a dataflow language of communicating finite-state machines,
• an inner expression layer - stateless and purely functional, mapping input patterns to output expressions in Haskell-like style.

State lives only in the wiring (a wire can be initialised with a value, and a box can feed its own output back to an input), so each box body stays purely functional and analysable, while the coordination layer provides the reactive, concurrent behaviour an embedded controller needs.

The canonical small example - this one adapted from the community’s LiteratePrograms archive - shows all three pieces at once. The box counts as it greets, feeding its counter back to itself while routing the printable tuple to standard output:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

stream output to "std_out" ;

box hello
in (count_in::int 32)
out (count_out::int 32, shown::(string, int 32, char))
match
 99 -> (0, ("Hello World ", 99,'\n'))
 | count -> (count +1, ("Hello World ", count,'\n')) ;

wire hello
   (hello.count_out initially 0)
   (hello.count_in, output) ;

The ladder of Humes

Hume’s most distinctive contribution is that it is not one language but a nested family, each level a sublanguage of the next, each with different formal properties:

The idea is that a developer writes at the highest level the problem needs, and the toolchain tells you what guarantees survive. A hardware interface might live in HW-Hume with everything decidable; a control loop in FSM-Hume with hard space and time bounds; only the parts that truly need general recursion pay the price of undecidability. Few languages before or since have made “how analysable is this program?” such an explicit, graduated dial.

EmBounded: putting the proofs on the road

The theory met practice in EmBounded (2005-2008), a €1.26M EU Framework 6 project (IST-510255) coordinated by Hammond at St Andrews, with Heriot-Watt, Ludwig-Maximilians-Universität München, the French LASMEA laboratory in Clermont-Ferrand, and the timing-analysis company AbsInt GmbH. Its goal was to automatically identify, quantify and certify resource bounds for Hume programs, evaluated against realistic applications from real-time control and computer vision.

The results gave Hume its best war stories. Researchers at LMU Munich and St Andrews developed new theoretical models - in the amortised-analysis tradition - that predict dynamic memory and time usage directly from Hume source code. AbsInt’s aiT analyser supplied worst-case-execution-time figures for the compiled code, the same class of tool used to certify avionics software. Prototype Hume implementations ran in under 30KB on a standalone Renesas M32C development board, according to the project’s 2006 report in ERCIM News - a striking footprint for a language with higher-order functions and automatic memory management. And the showcase application was real-time vision: LASMEA researchers wrote road-feature-detection algorithms in Hume, intended for CyCab, the laboratory’s small autonomous electric vehicle - reportedly capable of speeds up to about 30 km/h.

Toolchain and evolution

Over its life the project produced a full research toolchain: a Hume interpreter, the prototype phamc compiler targeting the Hume Abstract Machine (HAM), the later humec compiler (final recorded release 1.0.3, November 2008), an extended HAM interpreter, and the hamdb debugger. The last stable language release is recorded as version 0.8, on April 25, 2008. Reference implementations ran on ordinary developer machines of the era - the language’s Wikipedia entry records IA-32 and PowerPC support on Linux and macOS - alongside the embedded targets developed in EmBounded.

After EmBounded, the EPSRC-funded Islay project (2008-2011) at Heriot-Watt carried the research forward into areas including image processing, vision and control. The Heriot-Watt project page records the Hume effort as running “from around 2000 to 2013”; after that, development stopped. The language is dormant: the reports, papers, interpreters and compilers remain archived on the university sites, but there is no active community, package ecosystem or maintained distribution.

Why it matters

Hume never escaped the research world, and it is fair to say no mainstream language descends from it. Its importance is of a different kind.

It took cost seriously as a language-design problem. Most languages treat resource usage as an implementation detail to be measured afterwards. Hume made “can we statically bound this program’s space and time?” the organising principle, and its ladder of sublanguages remains one of the clearest demonstrations that expressiveness and analysability can be traded deliberately rather than surrendered wholesale.

It proved functional programming could fit a microcontroller. A pattern-matching, higher-order, garbage-collected language running in under 30KB on an embedded board, with machine-checked memory and timing bounds, was a genuinely provocative demonstration in the mid-2000s - and remains relevant as functional techniques continue to press into embedded and safety-critical domains.

It carried a research lineage bigger than itself. The amortised resource-analysis techniques sharpened on Hume during EmBounded fed a research tradition of automatic resource-bound inference that has long outlived the language. Like its philosopher namesake - who was famously sceptical about what can be known with certainty - Hume the language was an extended, rigorous inquiry into exactly how much a compiler can promise. The answers it found are still cited; the language that asked them sleeps in the archives of two Scottish universities.