Hello Nicola et al., I have only learned about your CinC effort during last week with the news about core.typed. I have ported the analyzer of the self-hosted cljs compiler to ClojureC: https://github.com/schani/clojurec/pull/33 and can explore it from the metacircular scheme REPL already. It seems to work basically, but dynamic runtime primitives like namespaces, dynamic protocols, records, ... needed for the compiler are lacking.
I want to proceed to a native REPL and statically compiled primitives in C which then can be used to interactively build and explore runtime design on this native REPL (linked C-libraries can be called natively and will be garbage collected as well if done properly). I *don't* see this as competition for any established runtime and I still would define ClojureC as the host and the environment as "hosted" as I really appreciate Clojure's hosted approach of decoupling the runtime from the language. I haven't sorted that out yet, though, as it means deciding how to link against libraries of the host (e.g. glib). The motivation for the project is/was to write a Clojure runtime in Clojure itself with the help of ClojureC (mostly to learn about compilers and runtimes as I only develop with Clojure for 10 months now). I can picture it as a simple barebone which could be used to hook in https://github.com/halgari/clojure-metal/ or http://blog.danieljanus.pl/blog/2013/05/26/lithium-revisited/ into an already working REPL and explore (mixed) runtime building from there and lift JIT compiling and different runtime optimizations independently from this minimal Clojure implementation while adding the necessary static support for performance. The immutability aspects of Clojure also potentially allow more aggresive JIT optimizations through memoization, but this is only my speculation. Up until now I just wanted to hack the compiler together to get some minimal Clojure REPL going before asking for help on this list (working with statically compiled C sucks feedback-wise). My idea was to use ClojureC's runtime closures like SICP does instead of an explicit bytecode to emit. I pictured that as Clojure in Clojure defined only in terms of the lambda-calculus (closures). But now I have doubts. I thought that a bytecode compiler could be done additionally/independtly and through rebinding of vars in the ClojureC runtime additional JIT compilers like the LLVM one of halgari could use their own bytecode (even different compilers/bytecodes during one runtime) to optimize these functions transparently. It would implement Clojure in Clojure completely without bytecode, but then this possibly defeats performance and does not make the barebone suitable for embedded applications (as memory consumption might bloat). It will be fairly slow anyway, but this is atm. no problem for me. Now I am thinking about porting CinC instead and defining a native bytecode with you inspired by CinC needs and other bytecodes. I want to do that as a long-term project, the runtime will have little use in the near future as NodeJs and Lua are probably better hosts even for embedded applications. What do you think? Christian -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
