A parallel set of contribs matching the clojure.java.* libs does make
sense.  Some already exist.  As part of the core distribution, there
are clojure.clr.io and clojure.io.shell.

There are several levels of porting difficulty.

(1)  libs with very little interop, hence requiring little or no
editing to port.  clojure/walk.clj is like that.
(2)  libs that are essentially wrappers around a platform library.
clojure.java.io and java.jdbc are examples.
(3)  the rest.  An example is data.json.

Case (1) is easy.

Case (2) usually means no port, unless there is a platform library on
the other platform that is close.  In the case of clojure.clr.io and
clojure.java.io, you really have to write a different set of functions
to reveal the underlying capabilities.  In fact, when I wrote
clojure.clr,io, I probably preserved a little too much of the
structure of clojure.java.io, rather than doing a complete redesign
from the ground up.

A different example of case (2) is not a separate lib: the functions
related to regular expression handling in clojure/core.clj.   Regular
expressions between the two platforms are just enough different that I
couldn't port by simple changes in interop calls.  There are
significant enough differences handling iteration state that I had to
exert some actual thought.  Still, I could maintain the clojure-side
API without change.

Case (3) is tough.  I can't say that I have enough experience to fully
categorize the possibilities.  But let's use data.json as an example.
I have ported it (but not published it yet).   Something like 84
changes to interop calls, plus changes to type hints.  Almost all due
to calls on I/O.

(:import (java.io PrintWriter PushbackReader StringWriter
                    StringReader Reader EOFException)))

I had to make minor changes to algorithms in a few places.    Could
the original have been written to make porting easier?  I can think of
a few ways to do that, but the best ways require read-time
conditionalization and Rich is against that.  Would writing against
clojure.java.io instead of directly against java.io have helped.  Not
much.  Copy and edit is about the only real solution.

I've probably said too much already.

-David


On Nov 3, 12:54 pm, Sean Corfield <[email protected]> wrote:
> On Thu, Nov 3, 2011 at 10:35 AM, dmiller <[email protected]> wrote:
> > An analysis of the 2011 ClojureCLR survey and a plan of action is now
> > available here:
>
> >http://clojureclr.blogspot.com/2011/11/survey-says-call-to-action.html
>
> Nice set of analyses David - great work!
>
> On this 
> one:http://clojureclr.blogspot.com/2011/11/survey-says-port-those-libs.html
>
> I wonder if we neet to consider a parallel set of contribs for
> ClojureCLR that match clojure.java.*? That would seem to help with
> interop and ecosystem which are two other points on the survey.
> clojure.net.* is likely to be open to misinterpretation, I suspect, so
> clojure.clr.* would seem more logical?
>
> I don't know enough about .NET / CLR to help (although I'm curious)
> but I suspect a "port" of clojure.java.jdbc to clojure.clr.ado or
> something similar would be useful?
> --
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View --http://corfield.org/
> World Singles, LLC. --http://worldsingles.com/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to [email protected]
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Reply via email to