This is so cool! I just had a daydream of combining Lisp with llvm, googled it and then ended up here. :) And I absolutely agree with you on Lisp macros. The macros are a killing feature of Lisp IMHO.
llvm is such a wonderful tool for people writing compilers!! And it’s developed by someone at UIUC and I’m so excited when I learned it because I’m going to attend uiuc this fall!!
Common Lisp is indeed a long lasting "local optimum" for programming. It is fast, has enough core functionality to get you started with a project without having to hunt for libraries (you can, but you are not forced to like you are in other languages, which are "minimalist"). The only drawback which annoys me is that all implementations use pointer tagging, so, if you REALLY need a 64 bit fixnum, not boxed, you are out of luck. sbcl: (log most-positive-fixnum 2) >> 62.0 clasp: (log most-positive-fixnum 2) >> 61.0 Common Lisp would be perfect, if there was an implementation which has 64 bit fixnums.
Always liked c style languages but learned clojure recently and liked it too. Not sure how it compares to clisp in terms of speed and macro capabilities.
Clojure is generally slower than SBCL, there is a heavy price to being hosted on the JVM. The macro capabilities are similar however. Be careful with the word "clisp" there is a dormant Common Lisp implementation called "clisp" so it should not be used to mean "Common Lisp" itself. I would say Common Lisp is the more "lispy" of the two as most people using Clojure don't have a Lisp background in general so they drag in habits from non-Lisp languages this spills over into the libraries favoring things like hashmap dispatch over combinators and also hashmaps over functions with heavy destructuring rather than abstracting and reusing.
He uses a lot of existing code to implement CL (Like SICL), and because it has LLVM internals exposed in CL and presumably uses C++ style object style storage internally it will be much easier to co-mingle with C++ going into the future. Also, he can target any LLVM backend architecture with his CL code so it can be relatively easily adapted to modern compute architectures (Supercomputer, GPU, etc.).
@spaceLem what are limitations of Julia's macro system? Just that it's practically harder to use because the language has rich syntax and you need to keep that in mind?
It can be or it can be in a different language. In the past, they've implemented C using Lisp. More about that here: en.wikipedia.org/wiki/Genera_(operating_system)
@FichDich InDemArsch My example was just concrete evidence that C or C++ is not strictly necessary to implement Common Lisp. There are even systems where C and C++ are not available out of the box instead you might have a horrid language like IBM RPG. For most common computers, C and C++ are probably the way to go. You can't necessarily implement any language in any language. If you've got a high level language which can't access hardware but the language you're implementing, language B needs to access hardware, say display to screen as part of the language spec you can't get there. Some languages especially dialects of BASIC can render shapes and such as part of the spec, if you've got a language which can't get at the display driver say Scheme (R5RS only), you're not getting there.
