I'm developing a programming language called Kernel. Kernel is a conservative, Scheme-like dialect of Lisp in which everything is a first-class object.
"But," you may ask, "aren't all objects first-class in Scheme?" (I'm glad you asked.) No, they aren't. Special-form combiners are second-class objects. To borrow a phrase from the original description of first- and second-class objects by Christopher Strachey, they have to appear in person under their own names. (There are also several other kinds of second-class objects in Scheme, but special-form combiners are the most commonplace.)
The idea of first-class operative combiners, i.e., first-class combiners whose operands are never evaluated, has been around a long time. Such creatures were supported by mainstream Lisps through the 1970s, under the traditional name fexprs, but they made a mess out of the language semantics because they were non-orthogonal to the ordinary variety of procedures constructed via lambda — and, more insidiously, because at that time the mainstream Lisps were dynamically scoped (a language feature that causes more problems for fexprs than it does for the less powerful macros).
Kernel eliminates the non-orthogonality problem by breaking the classical lambda constructor into two orthogonal parts, one of which is the Kernel constructor for first-class operatives.
First-class operatives aren't all there is to Kernel, just the most immediately obvious difference from most Lisps. The mandate of the Kernel language is to have a clean design, flowing from a broad design philosophy as refined by a series of more specific design guidelines — just one of which is that all manipulable entities should be first-class. Some other neat (IMHO) features of Kernel are
On the theoretical side, the primary resource is my doctoral dissertation, Fexprs as the basis of Lisp function application; or, $vau: the ultimate abstraction, which treats pure and impure vau-calculi. I gave a talk at NEPLS in fall 2007 that described pure vau-calculi (abstract ; script ; slides (PDF, not meant to be printed)). A pure vau-caluclus is also described (even more lightly) in Appendix C of the Kernel Report ("De-trivializing the theory of fexprs").
The place to look for implementations of Kernel, these days, is a blog post The Kernel Underground, at Manuel Simoni's The Axis of Eval. I do have my own pseudo-prototype implementation, called SINK ("Scheme-based Interpreter for Not-quite Kernel"), meant to be mostly compatible with unextended R5R Scheme; it doesn't recognize some Kernel tokens, it's slow as molasses... it runs, which is more than I can say for the Java-based interpreter I started years ago and never found time to finish. I've used SINK to debug library implementations for the Kernel Report, and to play around with guarded continuations. For whatever it's worth, here it is as a gzipped tarball: sink-01m10.tar.gz.