Forty years ago, Peter Landin wrote a profoundly influencial article, “The Mechanical Evaluation of Expressions” [38], where, in retrospect, he outlined a
substantial part of the functional-programming research programme for the following decades. This visionary article stands out for advocating the use of the
λ-calculus as a meta-language and for introducing the first abstract machine
for the λ-calculus (i.e., in Landin’s terms, applicative expressions), the SECD
machine. However, and in addition, it also introduces the notions of ‘syntactic
sugar’ over a core programming language; of ‘closure’ to represent functional
values; of circularity to implement recursion; of thunks to delay computations;
of delayed evaluation; of partial evaluation; of disentangling nested applications
into where-expressions at preprocessing time; of what has since been called de
Bruijn indices; of sharing; of what has since been called graph reduction; of call
by need; of what has since been called strictness analysis; and of domain-specific
languages—all concepts that are ubiquitous in programming languages today.
Wow, I had no idea that one person came up with all those concepts in one paper! Especially that de Bruijn indices were not invented by de Bruijn!
So what I’m thinking is the SECD Stack is the Forth stack, C is (almost) the Forth PC, D is a slightly more general (and perhaps more restricted) Forth Return Stack, and Environment… is very specific to the Lispy lambda way of calling, and isn’t needed for combinators or Forthlike calls. Could we get by with a three-register “SCR” machine backed by immutable cons storage? This might in fact be a terrible idea on many levels; I’m not sure.
(An SCR machine would hold the top of heap on the stack, so as well as lots of quality-of-life problems because the stack is hard to use and in Forth everyone uses RAM to escape from it, if you erased your stack you’d probably lose your whole OS. Oops. Maybe not so great.)