More Language Design Thoughts

There are two extensions that the INRIA people are unlikely to think about, and that's the avenue I'm pursuing: A) substructural types for pointer ambits, à la Cyclone; and B) some kind of support for concurrency, à la the Kell calculus.  The former one is a huge pile of work, but I can ape most of it by looking at the excellent work Morrisette and his team have already done.  The latter problem is where I think the real magic still lies.

Milner's book on the π-calculus contains a demonstration of how the λ-calculus can be embedded in it.  My hunch is that an explicitly typed, polyadic π-calculus can easily accommodate the whole of F-zip, plus whatever additional weirdness I can dream up.  I'm going to try to find out.  My interior language will look a lot like the Kell calculus (a π-calculus variant) extended with open existential types for first-class modules and substructural types for safe pointer ambits.  I'll be generating LLVM code that relies heavily on the recently added support of tail-call optimization for a continuation passing style (CPS) runtime that will look kinda like how Pict works (but with some additional optimizations for inlining unobservable pure functions).  That will make it look like a three-headed monster.

I should call my interior language KG, which would secretly be an abbreviation of King Ghidorah.

Thoughtful readers may be wondering why I'm taking the approach of starting with a functional surface language and embedding it into a process calculus.  The answer is that I've looked at all the programming languages with embedded syntax for a π-calculus variant.  There are a whole lot of languages like that, and they all strike me as making it too damned hard to write simple sequential algorithms, and let's face it: a lot of important algorithms are just cannot be improved by concurrent processing.  Consider insertion/deletion in red-black trees.  Concurrent— even parallel— processing is just not going to speed that up.  And sometimes, paying for the overhead of concurrency is just never going to be worth it, e.g. iteration on trees of small, bounded size.  Programmers will still need to manage concurrency explicitly for the foreseeable future.