Thursday, September 8, 2011

The Kernel Underground

A quick update on Kernel buzz:

There are now fourfivesixseven19 (I stopped counting) implementations of Kernel and Kernel-like languages:
Check them out for inspiration, and write your own. It's fun. Fexprs are fun exprs!

There are some interesting Kernel discussions going on in the Guile thread (and here) on LtU. David Barbour provides welcome criticism. (The truth can only be found in conflict. - Tarkovksy)

Oh, and I created this:

5 comments:

John Shutt said...

Tom Breton has been working on an interpreter called Klink, and blogging about it and Kernel for about a year now.

Tehom said...

Thanks, John. Klink lives at http://repo.or.cz/w/Klink.git.

Nightstudies said...

I dislike that Kernel bills itself as being about fexpers - in lisp fexpers were very different, they didn't require you to specify (and possibly change) an environment every single time the compiler/interpreter saw a symbol - it was a lot more efficient.

Deferring every single step of a compiler, even that of matching a an atom to an environment until the very last stage of interpretation is much slower than old style fexprs that just needed two paths on function calls, evaluated and unevaluated.

Tehom said...

John can answer for himself, but the idea has always been that compilation would include partial evaluation, so the formal delay until the very last stage is not necessarily an operational delay.

nightstudies said...

Tehhome, except that usually environments are optimized for specialized uses as static offsets into specialized base pointers or object pointers or class variable pointers held in registers, or resolved to static variables, or even different optimized versions of slots - each case optimized to a very specific implementation of that.

But Kernel doesn't have pre-built specialized implementations of environments, environments are created in user code and can be any sort of spaghetti the user wants. And in computing there isn't ONE implementation of objects or modules or any of those things - it's just important the the compiler know ahead of time what model is used so that it can optimize to it.

So it would be very hard indeed for a Kernel system to analyze a users code, figure out which kinds of patterns of environment inheritance the user has created over and over, find the most efficient flattened model of it, and put that in the code.

Kernel very much breaks the mapping from user code to machine code that was the original purpose of high level languages.