To Do

In no particular order, here are some of the pending development tasks.

Implement printf

The format function in core.clj depends on Java’s String.format, a printf-style formatter. There is no BCL equivalent, so we will have to implement it.

This has been partially written. Still awaiting completion:

• extend integer spec to BigInteger arguments
• extend float spec to BigDecimal arguments
• extend float spec to System.Decimal
• implement DateTime spec
• implement HexFloat spec
• implement grouping for General Float spec
• implement grouping for integer spec / BigInteger arguments

Loading of standard environment

There are several .clj files that are part of the standard environment of ClojureJVM that we have not translated yet.

• clojure/xml.clj
  • The implementation relies extensively on SAX parsers as defined in org.xml.sax and javax.xml.parsers. This will require non-trivial rewriting to make it rely on BCL equivalents.
• clojure.inspector.clj
  • Swing doesn’t swing it in CLR-land. This will need to be rewritten completely to make it work with WinForms or WPF.

BigInteger and BigDecimal

We are relying on the java.math.BigInteger and java.math.BigDecimal implementation-s- found in vjslib in the Visual J# Redistributable package. I don’t like having this dependency and suspect that is not necessarily the most efficient implementation. Also, the implementation is based on the pre-Java 1.5 versions of these classes and thus is missing some needed functionality.

I suggest creating a class derived from Microsoft.Scripting.Math.BigInteger in Microsoft.Scripting.dll (part of DLR) to provide an analog to java.math.BigInteger and then build a BigDecimal class matching java.math.BigDecimal on top of it.

Class clojure.lang.BigInteger has been added. The next step would be to build a BigDecimal class matching java.math.BigDecimal on top of it.

Proxy and genclass

In ClojureJVM, these are defined in the bootstrap files clojure/core_proxy.clj and clojure/genclass.clj, a collective 1000 lines of Clojure code heavily tied to Java reflection and the ASM 3.0 bytecode library. These will require significant effort to rewrite.

Proxy is now mostly done. Remaining are:

• Implement bean (in core_proxy.clj).
• Test proxy implementation against
  • explicit interface method implementation
  • generics wherever

Genclass hasn’t been attempted yet.

Testing

There are more than 500 unit tests for the basic runtime libraries in the Clojure.Tests project. There are many gaps and omissions.

There should be a set of tests developed for compiler functionality. See the compiler tests in IronPython and IronRuby to get a sense of what should be done.

Finish automating the build process

The environment bootstrap *.clj files should be moved to project BootstrapCompile. They should be automatically copied to the appropriate clojure subdirectory. The resulting assemblies should be moved to the appropriate places in the Simple.Console and Clojure.Main projects.

Also, create a distribution of the assemblies needed to run ClojureCLR.

Finish implementing core.clj

Most of core.clj has been implemented. Those things not implemented typically had some problems.

await
await1
await-for

The Java version uses java.util.concurrent.CountDownLatch. Either use the new concurrency library for the CLR or implement the equivalent directly. The concurrency lib is at http://msdn.microsoft.com/en-us/concurrency/default.aspx. Using this would require distribution with this project. I haven’t thought about how hard it would be to implement the equivalent.

num

Doubtful this will be implemented. There is no CLR equivalent to the Java Number class.

make-array
to-array-2d

We need consideration of how to handle multi-dimensional arrays versus ragged arrays. JVM only has ragged arrays. See CLR Interop.

re-pattern
re-matcher
re-groups
re-seq
re-matches
re-find

Should be a straightforward translation from JVM regex calls to CLR regex calls. Done.

file-seq

Needs translation into CLR System.IO calls.

with-precision

We have no equivalent in the vjslib java.math.BigDecimal implementation. See above on reimplementing this.

seque

Depends on java.util.concurrent.BlockingQueue and .LinkedBlockingQueue.

resultset-seq

Works on instances of java.sql.ResultSet. I would argue this should not be in the core. What class should this work against in ADO.NET land?

iterator-seq
enumeration-seq

There is really only IEnumerator in CLR. We map both of these to clojure.lang.EnumeratorSeq.

format

Needs printf-style formatting. See above.

future-call

Depends on clojure.lang.Agent/soloExecutor (need to implement), but more worryingly on java.util.concurrent.Future. The CTP concurrency runtime has this, or we implement.

pmap
pcalls
pvalues

Most likely these could be done fairly easily at this point. I just haven’t gotten to them yet.

Unimplemented functions with dependencies on the above

• find-doc relies on re-pattern, re-matcher, re-find
• future relies on future-call

Optimize, optimize, optimize

Premature optimization may be a sin. That is not our problem here. ClojureCLR must be speeded up. The basic libraries seem to run just fine. For example, the reading time (no evaluation/compilation) for core.clj is close to the same. Improvements here will come at the expense of fine-grained analysis of the code generated by the compiler and perhaps an examination of some of the decisions made in implementing the current compiler.

Developing a set of microbenchmarks in Clojure code would be nice for experimenting with compiler variations and for comparing against the JVM version.

clojure-contrib

The various libraries in clojure-contrib should be loaded and tested here. Because those libraries often have JVM dependencies built in, a long-term solution requires a mechanism for maintaining dual JVM/CLR-interop in CLJ code.

An important first step here is just to run the test-is tests.

Mono

Test under Mono. (We need to get rid of the vjslib dependency first.)

Rework reflection code

It’s a mess. Needs systematic rewriting.

One special problem that’s been pointed out by several folks. DateTime has a no-arg c-tor accessible by reflection. However, it is permissible to create one. It yields the default value. Thus, (DateTime.) should compile to a default expression for DateTime.

Reflection warnings

On a related note, systematically run through all the reflection warnings generated while compiling the bootstrap files core.clj, etc. (Compare against what the Java version generates.)