Pico

Pico is a very small programming language - “as in 10⁻¹², i.e. very small”, its designers explain - created by Theo D’Hondt at the Programming Technology Lab (PROG) of the Vrije Universiteit Brussel (VUB) to teach the essentials of programming to first-year students of physics, chemistry, mathematics and biology. Its authors describe it as “a Scheme derivative that is equally powerful in the sense that everything - including programs and continuations - is first class”, but with three deliberate departures: “classic infix syntax” that looks like elementary calculus, “fixed size arrays” (tables) instead of Scheme’s pairs and lists, and “no special forms”: if, while, and and begin are ordinary functions, made possible by an unusual parameter-passing rule that the designers called call-by-function. The result was a language whose entire syntax fits in a three-by-four grid, whose complete meta-circular definition fits in about a thousand lines, and which a novice “masters … in [a] matter of hours” - yet which was expressive enough to carry a decade of VUB research into mobile agents, prototype-based objects and ambient-oriented programming.

Pico should not be confused with the pico text editor bundled with the Pine mail client, with the PICO-8 fantasy console, with the Raspberry Pi Pico microcontroller or with PiCo, an unrelated C++ data-analytics library of the late 2010s.

History and Origins

A course gone wrong (mid-1990s)

The story begins with Pascal. Wolfgang De Meuter’s 2004 dissertation, whose fifth chapter is titled “Pico: the History and Rationale of Pic%”, recalls that “after years of teaching Pascal in a computer science introductory course for freshmen in exact sciences other than computer science we had to face the fact that the overall results were deplorable. Many students kept on struggling with the syntax, static typing rules, the positioning of semicolons, the difference between procedures and functions, the necessity to compile and so on.” The lab - then called the Lab voor Programmeerkunde, later PROG - decided to redesign the entire course. Pure functional programming was ruled out because the students needed “the notion of a changing memory”; the obvious alternatives, Scheme, Smalltalk and the lab’s own Agora, were rejected because “their simple regular syntax and semantics even take our computer science students two years to master fully”. The target audience’s only experience of formal notation was calculus, so the new language had to look like calculus. It also had to be “as powerful and simple as Scheme”, extensible “in the same way Scheme, Smalltalk and Agora are”, and lightweight enough to need neither a Smalltalk-style environment nor Agora’s heavy message-passing semantics.

D’Hondt’s first evaluator was written in Scheme; its source files are headed “Lab voor Programmeerkunde VUB, 1995”, and the site’s download page preserves it as “Version 0.0 … the actual original code from 1995”. The website’s own account of the design is blunt about the trade-off being made: Scheme, Self and Smalltalk are “among the richest and most powerful programming languages in the world when it comes to expressiveness and dynamicity”, but “most people really do need a syntactic hold and are not able to produce software without it”, so “Pico can actually be viewed as an effort to render languages like Scheme palatable and even enjoyable to people unable or unwilling to make the intellectual effort necessary to grasp its elegance and power.”

From Scheme to C (1996-1997)

The Scheme prototype “prompted the idea of a single memory manager”, and Pico was ported to ANSI C, giving it the single contiguous memory space and compacting mark-and-sweep garbage collector that the 2004 paper describes as its tenth design concern. That C virtual machine, copyright 1997, is the core of what was later called Pico 1.0. It immediately became teaching material in its own right: from the 1996/1997 academic year the sophomore course Interpretatie van Computerprogramma’s II asked computer-science students to build a Pico VM “from the ground up” as “an 8000 line C program”, and a complete meta-circular evaluator was written in Pico itself to serve as the human-readable specification of the language - “a slight misnomer”, the paper concedes, “because the base-level does not share the representation of program expressions with the meta-level”. A 1999 lab report by D’Hondt, Sebastián González and De Meuter, “The design and rationale behind Pico”, described the syntax as “two-tiered”.

A research vehicle (2000-2004)

Although Pico “was originally designed for educational purposes, over the years, it has also become a small language-lab for experimentation with language features” (De Meuter). The first such experiment was Werner Van Belle’s Borg, a mobile multi-agent system that exploited the fact that Pico’s threads and environments are first-class, garbage-collected values: an agent’s entire computational state could be reified and sent to another machine mid-execution. Then came Pic% (“pic-oh-oh”), D’Hondt and De Meuter’s prototype-based object-oriented extension, presented at TOOLS Eastern Europe 2002 and at LMO 2003; Kris Gybels’ Sic%, a Smalltalk-hosted Pic%; and dPico, Tom Van Cutsem and Stijn Mostinckx’s 2004 licentiate thesis on distributed prototype-based objects. Pico 2.0, a rewritten C core copyright 2002, absorbed several of the ideas these projects needed - first-class dictionaries with dot-qualification, first-class continuations, symbols and a distinction between mutable definition and immutable declaration.

The language’s public high point was 2004. The pico.vub.ac.be site was rewritten around Pico 2.0 in February, with binaries for Mac OS 9, Mac OS X and Windows, a Java port and Dirk van Deun’s readline-based tpico for Linux and BSD. On 13 June, De Meuter, D’Hondt and Jessie Dedecker presented “Pico: Scheme for Mere Mortals” at the first European Lisp and Scheme Workshop, co-located with ECOOP 2004 in Oslo. Its opening is a small manifesto: Scheme “is arguably one of the most concise, expressive and elegant programming languages ever built”, yet “the use of Scheme in teaching has been in constant decline for the past decennium”, and “fewer and fewer professionals master fundamental concepts (ask recent computer science graduates to explain the difference between a closure and a continuation and prepare to be surprised)”. Pico is offered as “a programming model similar to Scheme that can lure people away from their day-to-day practice and expose them to the rich diversity of programming concepts in an easily recognizable setting”.

Withdrawal and afterlife (2005-2026)

By the time the site was written, Pico had already been withdrawn from the audience it was built for: “Currently Pico is no longer used as a tutoring language for its target group, but this is more a consequence of politics than of the astounding results we got with teaching Pico.” It lived on in the computer-science curriculum, “as a means to teach principles of language design, interpreters and virtual machines”, and in research: Dedecker’s AmbientTalk (2005-2006) took its object model from Pic% and its call-by-name parameters from Pico, and Van Cutsem’s AmbientTalk/2 kept Pico’s syntax for tables, assignment, infix operators and function calls. D’Hondt returned to the Pico VM once more in “Are Bytecodes an Atavism?” (S3 2008), where it is one of two case studies for the claim that an interpreter driven directly by the abstract grammar can compete with a bytecode machine.

The website was last edited in November 2009. Dirk van Deun kept packaging the C sources for Linux until January 2014 - the last tpico release integrates “a fix by Theo for crash caused by negative array sizes” - and a VUB student’s 2013 GitHub repository shows the sophomore course still setting exam projects on the Pico VM. Nothing has been released since. In May 2026 the English Wikipedia article on Pico was deleted for lack of independent sources, an ironic fate for a language whose designers had explicitly “omitted an exhaustive list of bibliographical references as this would probably have doubled the size of this paper”.

Design Philosophy

The site states four rules that governed the design:

1. “the semantics of Pico had to be as simple as possible even if this meant that a number of Scheme features became inaccessible”;
2. “the syntax of Pico had to diverge as little as possible from the syntax used in elementary calculus”;
3. Pico “had to be presented in as attractive a way as possible, sacrificing any performance constraint that stands in the way of ease-of-use, portability, interactivity and other similar concerns”;
4. “Pico as a language had to coincide with Pico as a tutoring system; the boundaries between programming and learning had to be totally removed.”

De Meuter’s dissertation frames the problem as a search for an empty intersection. Languages with an irregular keyword-based syntax (C, Pascal, Java) are easy to read but hard to write and hard to extend. Languages with a regular syntax without special forms (pure functional languages, Smalltalk, Self) are trivially extensible but force “manual thunkification” - wrapping arguments in blocks to delay them - and so are “often obscure, especially to novices”. Languages with a regular syntax with special forms (Scheme, Prolog, Agora) are easy to write and extend but “students have to meticulously ‘parse’ programs to read them”. The authors “were actually after … a language with a syntax as easy to read as keyword-based languages, as easy to write as ordinary calculus, yet as orthogonal in syntax and semantics as the languages with a regular syntax”. The key that unlocked it, they argue, was “a rather original parameter passing technique”, which is why the 2004 paper ranks “richer parameter binding semantics” above everything else that distinguishes Pico from Scheme.

Simplicity was pursued at the cost of speed. “Pico was designed with little regard for efficiency - and none at all if it compromised the semantical clarity of the language.” Environments are plain linked lists searched sequentially, which “impacts the performance of Pico enormously”, but the designers kept them “because of its influence on a novice programmer’s understanding”. The only performance claim they make is carefully qualified: a cache shadowing the global environment “already led to a Pico implementation that is only slightly less efficient than DrScheme” - no benchmark is given, and the comparison is the authors’ own impression of their interpreter against the PLT Scheme of around 2004. Likewise their educational claim is offered as “a coarse estimate”: “essential programming concepts can be acquired using Pico in less than half the time it takes using Scheme”, based on comparing the first-year programming courses for mathematics students (Pico) and computer-science students (Scheme) at the VUB.

Key Features

The three-by-four syntax grid

Almost the whole of Pico’s syntax is the product of two small sets. An invocation is one of three things - a variable reference x, a tabulation t[i] or an application f(a, b) - and each can appear in four modes: plain access, definition with :, constant declaration with :: (Pico 2.0) and assignment with :=. The twelve cells are the language:

Defining a table evaluates its initialiser once per slot, so t[10]: x() calls x ten times; defining an application binds a named closure; and since definitions, declarations and assignments are all expressions with values, x:=(y::(x:4))+5 is legal (it defines x as 4, declares y as 4 and then assigns 9 to x). “A novice Pico programmer masters the grid … in [a] matter of hours”, the paper says, and “an actual Pico evaluator is essentially required to provide specialized interpreters for these twelve expressions”; a meta-circular definition of the twelve “requires about 200 lines”.

Values and types

Pico 1.0 has seven kinds of value: numbers (integers), fractions (reals), texts (strings, with no separate character type), symbols, functions, tables and void. Pico 2.0 adds continuations and dictionaries. Variables are untyped; values are checked at run time by predicates such as is_number, is_table and is_void, and converted by number, text, char, ord, trunc and abs. Comments are written between backquotes. Strikingly, there are no booleans: true and false are two-argument functions that return their first or second argument respectively, in the style of Church’s lambda calculus, which is what allows if to be a plain function (see below).

`a first Pico session`
Pi: 3.14159
fruit01: 'orange
firstName: "Theo"
fac(n): if(n = 0, 1, n * fac(n - 1))
display("fac(10) = ", fac(10), eoln)

Operators are functions

Any name made only of characters from the set $ % + - | ~ & * \ / ! ? ^ # < = > is an operator, and unary and binary operators may be written in prefix or infix form; +(5, 2) and 5 + 2 are the same application. Precedence is fixed by the operator’s first character - relational (<, =, >, #, ~) binds loosest, then additive ($, %, +, -, |), multiplicative (&, *, /, \) and exponential (!, ?, ^) - so user-defined operators slot into the grammar without declarations:

x << n: x * 2 ^ n
255 << 4
!n: if(n = 0, 1, n * !(n - 1))
!5
a ++ b: a + b + 1
a ** b: a * b * 2
p <=> q: abs(p - q) < 1
1 ++ 2 <=> 1 ** 2       ` true: parsed as (1 ++ 2) <=> (1 ** 2)`

“Operators are nothing more than syntactic sugar and do not have any impact on Pico’s semantics … the parsing phase converts operator definitions into plain function definitions.” The one trap this sets for Lisp programmers is recorded in the site’s FAQ: test-variable: 1 does not define a variable but redefines subtraction with formals test and variable - “In Pico, words in identifiers are separated by underscores!”

Call-by-function: no special forms

Pico’s signature idea is that a formal parameter may itself be written as an application. A parameter written as a plain reference is bound by value; a parameter written as q() is bound to a closure built from the corresponding argument expression and the caller’s environment - “an extension of call-by-name, which we will label call-by-function”. The argument is evaluated only when the callee calls q(), and if the formal has parameters of its own, as in f(val), those become dynamically scoped variables visible inside the argument expression. Every Scheme special form falls out of this rule as an ordinary function:

{ true(consequent(), alternative()):: consequent();
  false(consequent(), alternative()):: alternative();
  if(cond, then(), else()):: cond(then(), else());
  p & q():: p(q(), false);
  p | q():: p(true, q());
  !p:: p(false, true) }

while(predicate(), expression())::
  { loop(value, boolean)::
      boolean(loop(expression(), predicate()), value);
    loop(void, predicate()) }

map(f(val), tab)::
  { idx: 0;
    res[size(tab)]:: f(tab[idx:= idx+1]) }

map(val * val, [1, 2, 3, 5, 7])   ` [1, 4, 9, 25, 49]`

In the map example, the call-by-function parameter f(val) is bound to the expression val*val, so the caller writes a “lambda” without any lambda syntax. The designers admit this “may possibly raise some eyebrows because of its - albeit limited - introduction of dynamic scoping”, but “in our opinion … this may do more good than bad, certainly in a teaching or prototyping context”. The native control structures (if, while, until, for, case) are implemented in C “for performance reasons”, but each can be redefined in Pico; De Meuter’s thesis shows Algol-like loops, a Scheme-like cond and a full exception-handling system written this way.

Named functions and variable arity

Pico “requires that all functions be named - and consequently, lambda-expressions are absent”. The evaluation of fun(par, ...): body binds a closure to fun whose environment contains that binding, giving recursion for free and replacing Scheme’s let, let* and letrec: “functions are the only scope constructor in Pico”. Variable arity comes from the @ construct, which binds a table of evaluated arguments to a single formal:

begin@tab:: tab[size(tab)]      ` evaluate all, return the last`
table@tab:: tab                 ` evaluate all, return the table`
sum@any:
  for(i: s: 0, void, i < size(any), s:= s + any[i:= i+1])
sum(1, 2, 3, 4, 5)              ` 15`

The parser sugars begin(e1, e2, ..., en) to { e1; e2; ...; en } and table(e1, ..., en) to [e1, ..., en], so blocks and table literals are also just function calls.

Tables instead of lists

“Much of the power of Scheme is due to the fact that it is list-based … In Pico this list-orientation was replaced by tables, i.e. arrays.” Tables are the only composite value: they hold data, implement argument lists, represent multidimensional matrices (unity[3, 3]: 0), and - because the initialiser is re-evaluated per slot - can build ragged structures (triangle[3]: t[i:= i+1]: j:= j+1 yields [[1], [2, 3], [4, 5, 6]]). Lisp-style pairs are simply tables of size two (p # q), and the site’s sample code shows cons-cells, lists, streams and stacks built from them. More importantly, Pico programs are tables: the abstract grammar is a family of tagged nodes - REF, APL, TBL, DEF, SET, FUN, TAB, NBR and so on - that “are a generalization of tables”, and the natives read, eval, print, tag, make, get and set let a Pico program parse, inspect, rewrite and evaluate other Pico programs.

First-class dictionaries, continuations and threads

In Pico 2.0 the current environment - the dictionary - is a value. capture() returns it, commit(dct) installs one, and a dot-qualified invocation S.push(123) looks the name up in dictionary S, provided it was declared (::) rather than defined; the choice between : and :: therefore doubles as visibility control. This gives Pico “a very simple module system that constitutes a first step towards objects”:

Stack(n):
  { T[n]: void;
    t: 0;
    empty():: t = 0;
    full():: t = n;
    push(x):: { T[t:= t+1]:= x; void };
    pop():: { x: T[t]; t:= t-1; x };
    capture() }

S: Stack(10);
S.push(123);
S.pop()

Continuations are a distinct type rather than disguised closures: call(expression(continuation)) evaluates its argument with continuation bound to the current computational state, and continue(continuation, value) reactivates it. The 2004 paper builds a trycatch(try(), filter(exception), catch(exception, value)) handler from these in a dozen lines. Under the hood the VM’s thread - a linked list of frames - is itself a first-class, garbage-collected value, which is what Borg used to migrate running agents.

The virtual machine

“Pico uses a single memory model for the representation of all entities manipulated by its virtual machine … and uses a single memory space and a unified garbage collector.” The abstract grammar “can effectively be viewed as the instruction set for the Pico virtual machine”, the idea D’Hondt later defended at S3 2008 against bytecode designs. The distributed C sources are small - the Pico 2.0 core is about a dozen files (PicoEVA.c, PicoMEM.c, PicoREA.c, PicoSCA.c, PicoNAT.c, PicoCNT.c, …) plus a PicoShell glue layer - and the whole package ships with MetaPico, the meta-circular evaluator in Pico. The README of the Linux package warns that “the current interpreter cannot be run reliably on processors that align data on 8-byte boundaries. (Think Sun SPARC.)”, and the 2009-2012 changelogs add a 32-bit build flag and finally make configure “abort on pure 64 bit systems” - the code assumes 32-bit pointers.

Evolution

The dialects built on Pico form a second line of evolution: Pic% (2002, prototypes and first-class methods), Sic% (Pic% in Smalltalk), Borg/CBorg (mobile agents, 2000-2002), dPico (distributed objects, 2004), ChitChat (De Meuter’s 2004 thesis language, “a direct intellectual descendant of Agora and Pico”) and AmbientTalk (2005 onwards), the only one still maintained.

Current Relevance

Pico is dormant. Its website has not changed since November 2009, its last release is a January 2014 Linux packaging of a 32-bit-only C interpreter, its mailing-list page on prog.vub.ac.be now merely redirects, and there is no public source repository, package or Docker image of the official implementation. The site and FTP archive nevertheless remain online at pico.vub.ac.be (plain HTTP and FTP), so the Scheme prototype, both C cores, the meta-circular evaluator, the sample code and the Pic%/dPico material can all still be downloaded and, with a 32-bit toolchain, built. What survives more visibly is the lineage: AmbientTalk, developed by the same lab, still carries Pico’s table, assignment, operator and call syntax. The deletion of the Wikipedia article in 2026 means the canonical descriptions are now the primary ones: the site itself, the 2004 Lisp-workshop paper and the dissertations of De Meuter, Dedecker and Van Cutsem.

Why It Matters

Pico is a rare thing: a teaching language designed by people who loved Scheme and set out to discover exactly how much of Scheme’s syntax could be surrendered without surrendering any of its power. Its answer - that infix operators, calculus-style calls, array indexing and curly-brace blocks cost nothing semantically if you are willing to give up anonymous functions and add call-by-function parameters - is a genuine contribution to the small literature on “no special forms” language design, and it foreshadows the syntax of later Scheme-flavoured infix languages. Its insistence on a single memory model and an abstract-grammar instruction set made it an unusually honest vehicle for teaching virtual-machine construction, and a surprisingly capable one for research: strong agent migration, first-class methods with dynamic scope and ambient-oriented programming were all prototyped on a language whose complete definition fits on a page. The designers were candid that “few of the ideas that helped shape Pico are truly original … the real contribution of Pico is the merging into one package of a number of language concepts that are more or less well understood.” That package taught a generation of Brussels science students to program in thirty hours, and its DNA is still visible in AmbientTalk today.

Further Reading

• The Pico website: pico.vub.ac.be - “What is Pico?”, “Pico in Brief”, the tutorial, “What makes Pico special?”, the meta-circular “Anatomy of Pico”, downloads (FTP) and sample code
• W. De Meuter, T. D’Hondt and J. Dedecker, “Pico: Scheme for Mere Mortals”, 1st European Lisp and Scheme Workshop (ECOOP 2004, Oslo, 13 June 2004); PDF on the Pico FTP server (Docs/LispWS.pdf)
• T. D’Hondt and W. De Meuter, “Of first-class methods and dynamic scope”, LMO 2003, RSTI - L’objet vol. 9, no. 1-2 (2003), pp. 137-149 (Pic%)
• W. De Meuter, Move Considered Harmful: A Language Design Approach to Mobility and Distribution for Open Networks, PhD thesis, VUB, 2004 - chapter 5, “Pico: the History and Rationale of Pic%”
• J. Dedecker, Ambient-Oriented Programming, PhD thesis, VUB, May 2006, §5.3 on Pic% and Pico; T. Van Cutsem, Ambient References, PhD thesis, VUB, 2008
• W. Van Belle and T. D’Hondt, “Agent Mobility and Reification of Computational State: An Experiment in Migration”, LNAI 1887 (Springer, 2001), pp. 166-173, doi:10.1007/3-540-47772-1_15; the Borg tutorial at borg.yellowcouch.org
• T. D’Hondt, “Are Bytecodes an Atavism?”, Self-Sustaining Systems (S3 2008), LNCS 5146, pp. 140-155