technology from back to front

‘Code as Data’ != Closures

Today I googled for “code as data”. The first hit that came up was [this](,+or+closures), a tutorial on [Groovy]( that cheerfully proclaims that what is meant by “code as data” is *closures*! No, no, NO!!!!

“Code as data”, aka “code is data” signifies the ability to *manipulate*
code, i.e. to construct and take apart programs. At the most primitive level that can be accomplished
by representing source code as strings, which is possible in most programming languages. Going beyond that, many
programming languages define an AST data structure, with a parser and
pretty printer, that allows manipulation of code in a more structured
manner, enforcing most, if not all, syntactic constraints of the

However, neither of these approaches fully capture what is meant by
“code is data” in the Lisp tradition. There code really *is*
data. There is no special AST data type and associated parser and
pretty printer. Instead all programs are represented in terms of the
ordinary data types of the language, such as symbols and lists. The
concrete syntax of programs is subsumed by the standard external
representation of data.

None of this has anything to do with closures.

  1. I’ve seen “code as data” used to refer to higher-order functions before – and it’s an interpretation that sort of makes sense: if you let “closure” mean “something to do with that code I wrote over there”, then being able to pass closures around as data really is code-as-data. It’s a fairly loose chain of reasoning, but it’s not wholly incomprehensible.

  2. Very true, and since it’s a wiki, I updated it. Hopefully this won’t cause any sort of confusion among the Groovy principals.


+ nine = 12

2000-14 LShift Ltd, 1st Floor, Hoxton Point, 6 Rufus Street, London, N1 6PE, UK+44 (0)20 7729 7060   Contact us