[FoRK] l.py --- musing about lisp implementations

[Jeff Bone]

A few years ago I did an incomplete port of Tim Budd's C++ port of  
Samuel Kamin's family of language interpreters to Python.  (I did this  
not because I wanted a Lisp to use, particularly, but rather merely to  
implement a Lisp completely from scratch --- my closest previous  
attempt had been hacking SIOD into a MUD engine in about 1990,  
followed by implementing a sort of mobile-agent Scheme EDI interface  
based on the SIOD architecture, reimplemented, while at Sun.)  Nb.  
Kamin's, thus Budd's and my own variations, are far from complete  
languages;  they have only integers, strings, and whatever the  
fundamental language data structures (functions, lists, arrays for  
APL, objects for Smalltalk, etc.) as data structures and no standard  
libraries or other generally-necessary facilities for practical  
programming.

I called this "polyglot" and intended it to be the foundation of a  
"language lab" (if only for my own use) for experimenting with  
different programming language concepts.  Kamin's interpreters were  
originally presented in this book [1] and span the gamut from minimal  
implementations of Lisp and Scheme to APL, Prolog, SASL, Smalltalk,  
and so on... with the "minor" difference that they're all presented as  
being faithful if minimal implementations of the respective language  
semantics, but with s-expression syntax.  This is an okay thing, as  
the intent is pedagogical rather than production.

Still, I find it somewhat fascinating that it's essentially a trivial  
exercise to implement any language's semantics, particularly Lisp-ish  
semantics, in a Lisp-ish syntax, in any language.

In my rant a few weeks ago about Paul Graham's Arc, I noted that it's  
a commonplace for e.g. Haskell hackers to whip up a Lisp  
implementation over a weekend.

This came across progeddit today;  it's one of the most concise ground- 
up bare-bones Lisp implementations I've seen.  It demonstrates, I  
think, if in an indirect way, the triviality of implementing all the  
fundamentals of Lisp in very little code in any other higher-level  
language.  I'm not sure what this says about Lisp;  perhaps that it  
is, in some way, a sort of universal "abstract" assembly language for  
the higher-order concepts of computation.  But I do think it  
underscores how little, in some way, PG and other would-be hundred- 
year language designers are accomplishing when they build Lisp  
interpreters, particularly ones that are implemented in and leverage  
some underlying Lisp.

   http://www.flownet.com/ron/lisp/l.py

It seems very clear to me that we're just polishing turds in pursuing  
this course of language evolution.  If you want fundamental  
improvements in programming language expressivity and hence programmer  
productivity, you have to approach things from a fundamentally  
different model of computation.  Erlang (join calculus), Haskell and  
other typed functional languages (equational reduction), Prolog (logic  
and Horn clauses), APL (linear algebra), and so on do this.  Yet  
Another Lisp does not.


jb