Praising Kernel (The Axis of Eval)(axisofeval.blogspot.com)
axisofeval.blogspot.com
Praising Kernel (The Axis of Eval)
http://axisofeval.blogspot.com/2011/08/praising-kernel.html
8 comments
I think I'll use this opportunity for a shameless plug: https://bitbucket.org/AndresNavarro/klisp
This is my ongoing project for a Kernel interpreter. It's already functional and it even has documentation. It is still, however, a work in progress!
This is my ongoing project for a Kernel interpreter. It's already functional and it even has documentation. It is still, however, a work in progress!
Also: have a look at https://github.com/manuel/schampignon (an interpreter for a Kernel-like language)
I generally agree with alot the autor said and I will surly check out kernel.
About JITs ----------------
I agree that Scheme missed the JIT thing. Most Scheme compiler are AOT but Scheme would be nice to do research in JITs for dynamic languages. Now we have it in JS witch is more complicated. It would be nice if there would be a fast and small JIT for Scheme that is good for learning. is there something like that? I know Racket has something like that but Racket is much more then just a JIT for Scheme.
About Clojure ----------------
I think the author missunderstands Clojure (not just in this article). The "see the need (... of eval)"-statment was not about eval in general. Clojure has eval. The statmand was about having eval in ClojureScript (Clojure that AOT Compiles to JS) and there is not a priorety because its need is much less then the usfullness.
Clojure wants to be practical now and not be revolutionary. It never said it want to be ideal it just makes the best of what we have.
About JITs ----------------
I agree that Scheme missed the JIT thing. Most Scheme compiler are AOT but Scheme would be nice to do research in JITs for dynamic languages. Now we have it in JS witch is more complicated. It would be nice if there would be a fast and small JIT for Scheme that is good for learning. is there something like that? I know Racket has something like that but Racket is much more then just a JIT for Scheme.
About Clojure ----------------
I think the author missunderstands Clojure (not just in this article). The "see the need (... of eval)"-statment was not about eval in general. Clojure has eval. The statmand was about having eval in ClojureScript (Clojure that AOT Compiles to JS) and there is not a priorety because its need is much less then the usfullness.
Clojure wants to be practical now and not be revolutionary. It never said it want to be ideal it just makes the best of what we have.
I've read about Kernel before, but this time I wondered if $vau is in any way related to 0 from Jot (the turing tarpit best apparently best used as a Goedel numbering).
Maybe I should just write jshutt...
Maybe I should just write jshutt...
there are certain similarities to other very-low-operator-count languages - the big difference is that with Kernel's fexprs, you can go from this handful of operators to a fully-featured language more expressive than Scheme, and do so with style. See the R-1RK - it builds up the whole language, sequentially, from the built-ins:
ftp://ftp.cs.wpi.edu/pub/techreports/pdf/05-07.pdf
ftp://ftp.cs.wpi.edu/pub/techreports/pdf/05-07.pdf
Unrelated to the content of the article but by the UI - is it just me or does have pitch black background with white text is a bad design for the eye?
It's not just you. White text on a black background is HORRIBLE design. That's why my Readability bookmarklet sees a lot of use.
Readability is just one click away http://www.readability.com/
Not that it makes a difference, but I believe R6RS provide first-class environments, too: http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-17.html
Edit: After looking through the Racket docs, I believe I was referring to were its namespaces.
Edit: After looking through the Racket docs, I believe I was referring to were its namespaces.
Where the author mentions that it is related to his doctoral dissertation, Fexprs as the basis of Lisp function application; or, $vau: the ultimate abstraction[1].
[1] http://www.wpi.edu/Pubs/ETD/Available/etd-090110-124904/