Lambda the Ultimate

Symmetric environments allow a much more natural way of dealing with this idea.

A more extensive paper covers how this is a new and interesting way to provide program and data structure expression types out of a single construct - the same construct used above.

I skimmed the paper, and I mustsay I am not sure why you say the proposal is more natural. I'll give it more thought when I have the time.

I like the idea of making everything (i.e., parts of the interpreter sate) first-class. However I assume this can be very confusing...

There are a couple of books that deal with reflection in Lisp, such as SICP and Lisp In Small Pieces (I love that book :), and you're right that the languages that result when you start doing things like this to refactor the implementation.

It's not confusing when you re-orient the paradigm of the language to support it. Symmetric Lisp is very non-traditional in its semantics, but it's actually fairly intuitive and useful once you get used to it.

In fact, there are direct applications of it to distributed or concurrent programming, using built-in lazy concurrency semantics.

I know how lazy semantics can be used to provide the equivalent of coroutines - is this what you are referring to? How does it help with distributed computing?

In this case, each element in a namespace/environment is only computed on demand, and this includes recursively-included namespace/environments. Since each element in an environment is computed independently and without a priori specified semantics (although you can introduce constraints), you can distribute the environment and have element evaluation threads block until their request for a value across a network connection is fulfilled, at which point they resume. There is a paper on this issue separately on ResearchIndex (currently down) with subject matter of "demand-driven concurrency" (Google it!). (Yes I have been scouring ResearchIndex for a couple of years now. =)

Incidentally, Slate has this same idea, using a different syntax. (Yeah, it's a shameless plug, but I am short on developer time. Even the documents are sorely out of date and dis-organized.)

Sorry for all the questions, but that site has always been a bit of an enigma - some interesting (but rather opinionated!) comments on languages and vague hints about what was to come, but nothing very concrete...

Yes, I'm the author. Slate's current state is entirely mis-represented by its own site. I also am pretty much the only thread of research and development activity. Tunes has way too broad a scope to attract the right kind of people, but in the end it may be worth it. Emphasis has shifted back from Slate to Arrow, due in complicated ways to Tunes' continual problem of not defining its problem and solution scope properly.

The opinionated views are entirely not my own. In fact I am more than willing to re-design the whole site, but my day job as a nuclear technician is just too overbearing on my time (but it will be over in a year). So I stick with research and exploratative coding for now. These recent developments will probably tell you as best as can be explained, particularly my open letter on the state of Tunes. For what it's worth, people who understand quite a bit and can actually contribute are a rare find among Tunes membership. I think the site drives them off as well. We're always looking for people who will give it the time it deserves, and who know how to ignore the site's de facto author. At any rate, we've definitely escaped the discussion scope, so either start a new one please or email me.

As Joe Marshall noted, "The difficulty with using such a form [the first-class environment in MIT Scheme] is that it destroys any possibility of compiler optimization. If you compile code with a (the-environment) form in it (in MIT Scheme), the compiler essentially throws up its hands and inserts code to call the interpreter." His post goes on to give more details: http://www.mailgate.org/comp/comp.lang.scheme/msg04358.html

The following message considers dangers of explicit locations from a different point of view: http://srfi.schemers.org/srfi-17/mail-archive/msg00075.html

Lexical scoping can be considered an optimization technique: we can find bindings in effect at any point in a running program merely by statically examining program's code. We only need to scan the text of the program up to the current point. When the environment is first class, we can't tell if a variable is bound without knowing the whole history of function calls -- i.e., without running the code. As Dijkstra noted in his famous letter about GOTO, the lack of a strong correlation between program's code and a process that executes that code harms not only a compiler but a programmer as well.