Problems To Solve

Compiler hell

The current ClojureCLR was implemented to be as close to the ClojureJVM compiler as possible. This was a good choice for the first version. However, accommodating the differences the JVM and CLR has led to some real kludges. Over time, it has become increasingly difficult to translate significant change in the ClojureJVM to ClojureCLR.

In addition, some of the problems pointed in the Clojure-in-Clojure document are really ClojureJVM compiler problems that also plague the ClojureCLR compiler. From that document, I would point out the following as desirable:

• "Provide discrete analysis phase yielding Clojure data structures capturing semantics of code." ** Currently the compiler is essentially a two-pass compiler: build an AST, generate code. The resulting code has semantic analysis all over, in both passes. We need to restructure into more passes. We might even consider embracing the Nanopass framework and consider implementing a DSL for this as they have done.

• "Split out type reflection into API", "needs protocols to hide actual reflection classes" ** For reasons stated below, we need much more sophisticated type analysis in the compiler.

• "Split out code gen into API" ** Having an intermediate IL representation before going to System.Reflection.Emit would allow for better analysis and much better debugging. We can build on work by Ramsey Nasser in Mage.

• "Remove warts from current design", "e.g. use of vars and binding". "explicitly pass environment" ** Definitely.

• "current code modifies environment to e.g. tag things as closed-over could turn into query against child tree" ** We will move to immutable/functional.

Working with types

TBD

Protocols top-to-bottom?

TBD

Handling types

Improving handling of assemblies

Value types first-class

Generic types first-class

TBD

Get rid of faked Java implementations

TBD