Hints: Yurii A. Rashkovskii’s Xi, Ian Piumarta’s COLAs.

(And obligatory self-plug for my thesis if you want Lisp threads that are as interruptible as Erlang threads.)

Yes, you could be right; we may have the expertise, but as you said, the will may not be there. That’s the hardest part to predict, and that’s why I hope it’ll be there before “the end of my lifetime.”

If it means anything, the relatively strong reception of this post (somewhere over 6000 or 7000 hits, pretty good for my simple little blog) has inspired me to play with writing an interpreter that incorporates some of these design elements. In particular those that don’t involve static code generation: I want to have a really friendly interpreter that will make the process of rewriting a program into a standard representation non-magical and understandable.

If anyone cares then perhaps we can worry about efficiency. Until then it is just a toy for my own benefit, and possibly others that may be interested in this sort of stuff.

But I disagree on the amount of time you think it’s required. Lisp took something like 20 years of computer experience. Scheme came a decade and a some years later, Common Lisp about the same amount later. So, even though we haven’t seen any new LISP-like language in some years, it means either the ones we have are good enough or extensible enough to incorporate new features (which they are), or LISP-like languages have stopped to appeal (which is somewhat true).

But it does not mean development on a new language is completely stalled. And if you take things into account, with the amount of knowledge we have today, trial-and-error experience, bad examples and greatly faster hardware, I don’t see how a driven group (or individual) with a significant knowledge of computer science (language design is no small thing) could not come up with a language similar to the one you proposed in a few years. It just takes what it always takes for inventions: necessity and knowledge. The last we have, the first is an arguable thing.

Is it? I would consider Lisp’s soul to lie in the syntax and the unity between code and data representation. I thought Bit-C was interesting because as long as they support prefix syntax one could emit Bit-C from just about any lisp rather conveniently.

In any case, I think a low-level lisp that can be conveniently be generated from a higher level lisp is what I’m getting at; this way those looking to extend lisp can employ the low-level constructs to avoid . For example: by some machination (like dependent types) to avoid bounds checking and type annotation, or just because one is writing say, a numeric code where I pretty much want something with most of the properties of C.

Bit-C sort of gets at this core idea for me, as does the HLVM for LLVM. Sadly, the former seems to be somewhat dead at the moment, but I’ve heard something in the past about starting back up as part of the LLVM project sometime after 2.0 (which somewhat recently is available now).

So we’ll see.

Some might suggest that any overhead from one library calling into another and into another is small potatos, compared to the amount of bandwidth needed to transport mass data such as audio or video. Ultimately, this has to be measured. However I point you to the jack, oss, alsa, portaudio style libraries that in some application cases call into each other to a very deep level. Audio skipping, anyone?

Because so little in Squeak is left to voodoo beneath the surface (“turtles all the way down”), I’ve found it a more interesting environment for experimentation with continuations than Scheme.