There are now fourfivesixseven19 (I stopped counting) implementations of Kernel and Kernel-like languages:
- SINK, by John Shutt. Scheme.
- klisp, by Andres Navarro. C.
- js-vau and vau.rkt by Tony Garnock-Jones. JavaScript and Racket.
- Hummus, Cletus, and Pumice, by Alex Suraci. Haskell, Atomy, and RPython.
- Schampignon, Virtua, and Wat by me. JavaScript.
- Klink, by Tom Breton. C.
- Karyon, by Jordan Danford. Python.
- εlispon, by Pablo Rauzy. C.
- fexpress, by Ross Angle. JavaScript.
- Qoppa, by Keegan McAllister. Scheme.
- Schrodinger Lisp, by Logan Kearsley. Python.
- squim, by Mariano Guerra. JavaScript.
- Nulan, by Pauan. Python.
- IronKernel, by Ademar Gonzalez. F#.
- Bronze Age Lisp, by Oto Havle. Assembly.
- Pywat, by Piotr Kuchta. Python.
- Wat.pm, by unknown. Perl.
- Extensible Clojure
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:
Tom Breton has been working on an interpreter called Klink, and blogging about it and Kernel for about a year now.
ReplyDeleteThanks, John. Klink lives at http://repo.or.cz/w/Klink.git.
ReplyDeleteI 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.
ReplyDeleteDeferring 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.
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.
ReplyDeleteTehhome, 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.
ReplyDeleteBut 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.