[I thought I'd slip this in while Rich has everyone distracted lazy sequences.]
What do you do when you love Lisp, are intrigued by Clojure, but have absolutely no projects at hand to test it out? Oh, and you have an interest in how dynamic languages are being implemented in modern virtual machine environments. You might implement Clojure on the CLR, I guess. So I did. At least, I have started. The project has reached the point where I need input from the community and especially Rich. Rich asked that I go public. So I will. (Though most certainly I would prefer to wait until the code is ... better.) The code will go up on clojure-contrib ASAP. I need input from the clojure-contrib project members on how they operate, where they want to put it, etc. This is definitely alpha-level, developer-only. Hard hats, goggles, and heavy gloves recommended. Goals: (a) Implement a feature-complete Clojure on top of CLR and the DLR (Dynamic Language Runtime). (b) Stay as close as possible to the JVM implementation so that the versions can stay in synch. That includes: (c) To the extent possible, use exactly the same boostrap *.clj files to define the environment. (d) Try to use some of the more advanced features of the DLR, where it makes sense to do so. (e) Spawn a cottage industry of people making Visual Studio extensions for Clojures. :) (e) Have fun. Status: Let's call it alpha. Not for the casual user, but developers might want to take a look. Stop here unless you really want status details. The basic runtime data structures--the persistent collections, namespaces/symbols/keywords, vars, refs, atoms, agents, etc.--are 95% complete. The remaining pieces are trivial. The LispReader is feature-complete except for #=. Call this 96% complete. There are currently 500+ unit tests on the basic data structures and the reader. Call this 34% complete. There are no unit tests on compiler. That would be 0%. This is not an interpreter. A compiler translates Clojure forms into DLR expression trees. DLR does its magic, i.e. compiles to MSIL, and computation happens. At the moment, there is not a single call to Reflection.Emit in the compiler code. (Though that will have to change soon.) It handles all special forms, can load most of core.clj, deals with macros, inlines, tags, CLR-interop, There is a basic REPL. core.clj loads with minor edits (java.util.Collection => System.Collections.ICollection, for example). Of roughly 425 def forms in core.clj, only 43 are commented out. 19 of those are for specialized array access, 6 for regular expressions -- nothing significant in terms of work. Of the 360 defs that load, most have been tested at a rudimentary level. However, the roughly 20 defs related to libs/loading/compiling definitely do not work. Call this 85% complete. core-print.clj also loads and seems to work. ants.clj runs. (The sim code is unchanged. The GUI was rewritten to Windows Forms.) 100%. The code is consistent with revision 1279 of the JVM code (Feb 13). It is running on release 10606 of the DLR (Feb 11). It is slow. Roughly 4X slower than Clojure/JVM on one or two very easy tests. (No need to comment on microbenchmarks.) This will be the focus of the next round of work. What's not there: Libs and loading -- lots of design problems because of the differences between JVM and CLR relating to classpaths, assemblies, etc. (Basic file loads can be done.) AOT/Compilation/gen-class Proxies Bootstrap *.clj files other than core.clj and core-print.clj -- Just haven't had time yet. Speed. So there you have it. I'll post again when the code becomes available on clojure-contrib. -- David Miller --~--~---------~--~----~------------~-------~--~----~ 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 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 -~----------~----~----~----~------~----~------~--~---
