Thursday, November 3, 2011

Survey says: port those libs

Clojure/contrib lib ports

I suspected this would be high on the list, but hitting #3 was a surprise.  This was one community task I thought people might get drawn to first.   For the most part, it's not that hard to do, and there are significant examples: all the files such as clojure/core.clj, gvec.clj, and xml.clj  in the main ClojureCLR distribution are ported libs. However, as one comment stated:
I haven't even really seen anything in terms of guidance / best practices to allow this work to be carried forward by others in a consistent manner.
 Okay, here it is:
Replace interop calls to Java methods with interop calls to CLR methods.
That covers most of it. I've managed to keep the port of clojure/core.clj to inline changes across almost 6000 lines of code.   However, more accessible examples might be useful.
Action item: Provide ports of key libs to 'prime the pump'.
Action item: Illustrate the porting process and provide more detailed guidelines in a future post.
The ongoing reorganization of the contrib libs will be big help in moving this forward.  It makes the mass of clojure/contrib more modular and gives clues to what are viable libraries.

The biggest problem  is not the effort to port but how to manage the code when done.  Ideally, the libs would contain JVM and CLR versions in one code base.  There are ways to write *.clj code that would lessen the burden of porting.  However, I don't see contrib lib authors taking on that burden.  And the mind-set is not there from the top:  Rich has been very clear on two points: there will be no conditionalized read mechanism; and that Clojure code involving interop is never intended to be portable.

So, at the moment, it appears that parallel projects, with 90% duplicate code, is the only option.  Duplication carries the burden of maintaining consistency.  
Action item: Find a way to manage maintenance of ported libs.
Which contrib libs should be done first?

No comments:

Post a Comment