In my previous post on Homoiconic Python, I explored McCarthy’s Lisp, a language where code and data are the same thing. But there’s another path to expressive power, one that emerged in parallel.

At the 1956 Dartmouth conference, John McCarthy encountered Newell and Simon’s list-processing language IPL. He liked the idea of lists but hated the language itself, so he spent the next two years building Lisp at MIT. That same year, Kenneth Iverson was teaching mathematics at Harvard and growing frustrated with the inadequacy of conventional notation for expressing algorithms. He began inventing his own, publishing it in 1962 as A Programming Language, the book that gave APL its name.

APL looked like nothing else. Iverson designed a new alphabet, like Egyptian hieroglyphics, each symbol a complete idea:

APL is very expressive. Here is the complete implementation of Conway's Game of Life in APL:

      life ← {⊃1 ⍵ ∨.∧ 3 4 = +/ +⌿ ¯1 0 1 ∘.⊖ ¯1 0 1 ⌽¨ ⊂⍵}

And just like Lisp, APL had one data structure: the array. Lisp had the list.

This shared minimalism is the first hint of a deeper, ancestral bond.

Lisp was born at MIT; APL at Harvard. Lisp processes lists; APL processes matrices. Lisp inherits from Church’s lambda calculus; APL from Curry’s combinators. Lisp was designed for machines to do symbolic reasoning; APL was designed for humans to communicate mathematical ideas. One prioritizes semantic elegance, the other syntactic density.

In 1979, Alan Perlis (the first recipient of the Turing Award) chaired a panel asking: ”APL and LISP—should they be combined, and if so how?” The panel debated embedding one within the other, or generalizing both into something superior. No conclusion was reached. That same year, Iverson received his own Turing Award and delivered his famous lecture: Notation as a Tool of Thought.

Iverson’s Ghosts

You’ve probably used Iverson’s ideas without knowing it. John Baker calls NumPy an ”Iverson ghost”, APL’s array programming reborn in Python’s syntax. Broadcasting, vectorization, reduction along axes-these aren’t NumPy inventions. They’re Iverson’s ideas from the 1960s, wrapped in `np.` prefixes and spelled out in English.

PyTorch, TensorFlow, JAX-the entire deep learning stack speaks Iverson’s dialect with extra syllables. `np.arange(10)` is `!10`. `np.cumsum(x)` is `+\x`. `x[::-1]` is `|x`. Same concepts, more typing.

The Prophecy Fulfilled

Arthur Whitney, Iverson’s protégé, saw both languages clearly. On kparc.com (his personal website) he listed K’s lineage simply as “lisp and apl,” linking to Iverson’s Turing paper and Perlis’s lyrical programming. In a 2009 interview, he explained: ”I much preferred implementing and coding in LISP, but once I was dealing with big data sets... APL just seemed to have the better vocabulary.” He understood their complementary strengths: ”What I liked was the original LISP, which had car, cdr, cons, and cond, but that was too little. Common LISP was way too big, but a stripped-down version of APL was in the middle with about 50 operations.”

Whitney first encountered APL at age 11, when Iverson (a friend of his father’s) demonstrated interactive programming on a terminal in 1969. But it wasn’t until 1980, working alongside Iverson at I.P. Sharp in Toronto, that he began using it seriously. Through the ‘80s he explored broadly, implementing his own object-oriented languages, various Lisps, and Prolog. In 1988 he joined Morgan Stanley and built trading systems using his own APL dialect, which became A+.

Incunabulum

In 1989, Whitney visited Iverson at Kiln Farm. Iverson and Roger Hui were working on a new APL dialect-one that would use ASCII instead of special glyphs. Over one afternoon, Whitney wrote the now famous incunabulum. A one page interpreter in C.

That’s Arthur’s style: C that looks like APL. Macros turn C into a higher-order language; by the time he writes the interpreter, he’s writing APL in C. It looks alien at first glance, then you see it. This is code golfing at its earliest (popular among APL hackers long before Perl coined the term).

Roger Hui studied that page for a week, then wrote the first line of what would become J. J shipped in 1990, the first ASCII APL. But Whitney wasn’t done.

K

In 1992, Whitney created K. Where J modernized APL’s syntax, K transformed its semantics. On kparc.com, he laid out exactly what K inherited from each parent:

The parallels are striking. Both functional. Both dynamic. Both built on atoms and lists with maps between them. Both with REPLs and lexical scope. The syntax differs (s-expressions versus m-expressions) but the bones are the same.

The Lisp features crept in gradually. Lambda and conditionals appeared in the 1970s. Higher-order operators-map and reduce-arrived in 1979, the same year Perlis posed his question. ASCII came with J in 1989. But the decisive break was 1992: K abandoned APL’s multidimensional arrays for nested lists-Lisp’s data structure.

APL & Lisp, after four decades of parallel evolution, finally merged as k.

K Verses

This is what K looks like (using the 90 lines python implemntation from next section). Factorial:

 */1+!5

120

Average:

 (+/x)%#x:!100

49.5

Primes under 50:

 &2=+/0=(a)mod/a:1+!50

[2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47] 🤯

Golden ratio via continued fraction:

 0{1+1%x}/1

1.618033988749895

Fibonacci:

 5{|+\x}\1,2

[[1, 2], [3, 1], [4, 3], [7, 4], [11, 7], [18, 11]]

Pi via Madhava series:

 4*+/(-*\-_a%a:1+!n)*1%1+2*!n:1000000

3.1415916535897743

Euler’s number:

 */x*1+1%#x:_x%x:1+!1000000

2.7182804690959363

Square root of 2 via Newton:

 1+100{1%2+x}/1

1.4142135623730951

A Python Implementation

How do you build K in Python?

The data structure is already there, Python lists can represent Lisp lists (as I showed in my previous post). The symbols? K already uses ASCII. What’s missing is what makes APL special: everything is vectorized. We need scalar extension. Then parser/eval, this is where we lay the syntactic sugar, the notation if you will, of APL on top of Lisp. Lisp is semantics, APL is syntax.

Scalar Extension

Enter monad and dyad. Two higher-order functions that vectorize *any* Python function:

atom = lambda x: isinstance(x, (int, float, str))
monad = lambda f: lambda x: f(x) if atom(x) else list(map(monad(f), x))
dyad = lambda f: (lambda x, y: f(x, y) if atom(x) and atom(y)
  else list(map(lambda yi: dyad(f)(x, yi), y)) if atom(x)
  else list(map(lambda xi: dyad(f)(xi, y), x)) if atom(y)
  else list(map(lambda xi, yi: dyad(f)(xi, yi), x, y)))

Monad lifts a unary (one argument, i.e. f(x)) function. Dyad lifts a binary (two arguments, i.e. f(x,y)) one. They recurse into structure until they find atoms, then apply. This is scalar extension, the heart of array programming.

Watch what happens:

>>> import math

>>> sqrt = monad(math.sqrt)

>>> sqrt(4)

2.0

>>> sqrt([4, 9, 16])

[2.0, 3.0, 4.0]

>>> sqrt([[4, 9], [16, 25]])

[[2.0, 3.0], [4.0, 5.0]]

>>> add = dyad(lambda x, y: x + y)

>>> add(1, 2)

3

>>> add(10, [1, 2, 3])

[11, 12, 13]

>>> add([1, 2], [10, 20])

[11, 22]

Any function. Any depth. No loops. No NumPy. Just two higher-order functions.

dyad function works exactly like this:

• atom + atom → apply directly

• atom + list → extend the atom (scalar extension)

• list + atom → extend the atom (scalar extension)

• list + list → pairwise

monad function makes functions pervasive, it penetrates into nested structures recursively.

These two functions are what inspired me to build the whole thing.

90 Lines Later

Armed with scalar extension and a feel for K’s semantics, I wanted to see how far terseness could go. I wanted to implement the whole thing in under 100 lines of Python, honoring the tradition of my predecessors. Here it is:

Lisp: code is data. Empahsis on semantics.

APL: notation is thought. Empahsis on syntax.

K: both.

Less is more.

For more details, check out k.py on GitHub.

The idea of a programming language being able to implement itself is fascinating. It stirs an intense feeling of curiosity: "What would that even look like?" Since its inception in the early '60s, Lisp has managed to do exactly that.

John McCarthy, In the early '60s, unlocked a collection of remarkable ideas that work really well together and continue to be relevant decades later. First through the Lisp paper, and shortly thereafter with the Lisp 1.5 manual.

One such idea is homoiconicity, a trait where code and data are interchangeable. Typically, we think of code as a sequence of operations acting upon data. This understanding shapes our view of most programming languages today. However, Lisp breaks this mold by treating both code and data as the same—what's famously known as its homoiconic nature. This distinct characteristic effectively blurs the lines between the operator (code) and the operated (data).

This unification of code and data in Lisp is profound, it allows a level of expression where the language can be naturally expressed in itself.

This tiny card is the entire programming language of Lisp! A programming language written in itself. Here is famous quote from Alan Kay about this piece of coding history:

Okay, but what sort of magic did Mr. Kay see in this artifact that led him to call it the "Maxwell's Equations of Software"? How was the entire world of programming encapsulated in just a few lines of code?

One fun way to answer that, of course, is by applying the principle that: "In order to understand something, you need to code it".

And to keep this spiritual implementation of the original Lisp fun and fresh, I decided to pick Python as the tool of choice. Most programmers are either not familiar or not comfortable with Lisp's syntax (too many parentheses), but probably quite familiar with Python's syntax. My idea is to rewrite the "Lisp in Lisp" code in Python and try to maintain as much of the spirit of the old code as possible.

Strange yet familiar

Lisp originally, and quite brilliantly, came with two syntactical flavors. A code flavor named M-expression (short for meta) and a data flavor named S-expression (short for symbolic). They're semantically equivalent.

The "Lisp in Lisp" code presented earlier is written as an M-expression (code flavor) and implements an S-expression Lisp (data flavor).

One little trick to get us going is by translating Lisp M-expressions into Python code constructs, such as function calls and conditional statements. Additionally, we can represent Lisp S-expressions using Python lists. Lisp is short for "List Processing" because it only uses one data structure: the list. Therefore, it makes perfect sense to use Python lists to emulate Lisp S-expressions. Below, I present our mini dictionary that would act as our rosetta stone:

These are four ways of expressing one thing. They're all semantically equivalent.

An additional advantage of this mapping approach is that it eliminates the need to implement a parser for our language. This simplifies our code base and allows us to stay true to the original spirit of Lisp without getting distracted by string manipulations.

First iteration

With this context and motivation in place, we can move on to the actual implementation. Lisp requires a set of basic functions to be implemented outside of its scope, they're mostly about the basic building blocks of lists.

• Equivalence

  • atom(x): is x a list?

  • eq(x,y): is x equal y?

• Cutting

  • car(x): first element of the list

  • cdr(x): the rest of the list

• Stitching

  • cons(x,y): append an atom to a list

  • append(x,y): append two lists together

Ignoring a few recursive primitives, and with a little help from Llama3-70b (on Groq), we can quickly get a working interpreter for a subset of the "Lisp in Lisp" code:

Here are a few examples you can play with:

Full code available on github gists

Second iteration

Our first iteration is nearly complete, except for one crucial feature: lambdas. Lambdas are anonymous functions that serve as the primary method for defining and calling functions in Lisp. Without lambdas in Lisp, we cannot implement recursion, and without recursion, our Lisp would not be Turing complete (the minimum threshold to compute all which can be computed).

To incorporate lambdas, we need to add a few functions we previously overlooked, specifically two primitives: assoc(x,y) and pairlis(x,y). assoc(x,y) is a key/value dictionary style lookup but implemented with lists instead (associative lists). parlis is just the zip(x,y) in Python (ziping two lists together).

A literal translation in Python would be:

The original Lisp had to resort to recursion (function calling itself) even for simple, linear scans, since it had no loops. However, assoc and pairlis can be elegantly translated to Python using list comprehensions:

and if you hadn't noticed already I actually cheated a bit in the COND case as this in the original lisp was a evcon which was also translated into a loop. The same trick will be done again with evlis for the LAMBDA case.

We're almost there! There is one last thing, and we're done. The eval function actually takes two arguments in the original Lisp. The first is the expression (s-exp) of course. The second is the environment, which is yet another list (of key/values). Environment maintains variable binding for the LAMBDA case by mapping variable names to their corresponding values.  

For example, when you define a function with x variable then substitute that function with data, the data gets binded (with pairlis) to the x symbol and is then stored/appended to the environment list. When x is needed, it gets looked up (with assoc) and subtitued back to expression. The specific technique for this binding is known as dynamic scoping.

Here is the full 'Lisp in Lisp' code in Python:

Full code available on github gists

Find me on Twitter @aburjg

Helpful resources:

• https://inst.eecs.berkeley.edu/~cs61a/fa14/assets/interpreter/scheme.html

• http://languagelog.ldc.upenn.edu/myl/llog/jmc.pdf

• https://justine.lol/sectorlisp2