Porting Clojure to the CLR is hardly an original idea. Rich started with dual JVM/CLR implementations. And inquiries have been made on this group any number of times.
Regarding the library problem, I'm not exactly sure which problem you are referring to. Several things comes to mind. At the implementation level, there is the problem of loading the *.clj environment bootstrapping files. A common approach for Clojure, ClojureScript and ClojureCLR would push some JVM library calls in core.clj (for example) into RT. Type hints via tag metadata will require a more creative solution. Also, some Clojure API functions are JVM-specific and would need some modification. Those decisions are above my pay grade. At any rate, these problems should not surface to application programmers. At the application level, interop from .clj code with Clojure library classes should be portable because I've matched namespace/classname/ methodname pretty much across the board. If you have a lot of interop with JVM/CLR class libraries, I would imagine you would pick one and stick with it. In your example, if you have legacy JARs you need to interact with, you're in Clojure on the JVM. -- David On Feb 16, 10:50 pm, Sean <francoisdev...@gmail.com> wrote: > David, > You have a great idea here with porting clojure to the CLR. The .NET > shops are just a popular as Java shops, and something like this could > go a long way to improving software written by a lot of people. Your > initiative and hard work are to be commended. > > How do you plan on solving the library problem? As you mentioned, > there are several discrepancies between .NET and Java libraries. > Also, there will be applications written for a certain library that > might only be available in one of the platforms. I know I have > several .JARs that work with legacy applications ( like SAP & > Oracle :) ) that I need to use. If some else needs to maintain them, > I wouldn't want them to accidently try to run it on the wrong > platform. If it can go wrong... > > Of course, this is a problem open source systems have had for a while, > so it can be solved (apt,ASDF,rpm,rubygems...). It'll just take some > work. > > Good work overall, I'm looking forward to what you come up with. > > On Feb 16, 7:17 pm, dmiller <dmiller2...@gmail.com> wrote: > > > On Feb 16, 5:33 pm, Chouser <chou...@gmail.com> wrote: > > > > On Mon, Feb 16, 2009 at 5:43 PM, dmiller <dmiller2...@gmail.com> wrote: > > > > I don't know if you've looked at ClojureScript at all, but it's a > > > similar if noticeably less ambitious project to compile Clojure code to > > > JavaScript. It's in clojure-contrib already, but in > > > trunk/clojurescript instead of trunk/src. My reasons for this were > > > (1) I wasn't quite sure how to lay out the directory structure and > > > didn't want to mess up anyone else, and (2) it doesn't work with > > > Clojure trunk but instead requires a patch and rebuild of Clojure > > > itself. This patch is stored right there in contrib as well. > > > I have looked briefly at ClojureScript. > > > Placement: I'm guessing a parallel off-trunk placement. This code is > > completely independent of Clojure/JVM, except for the bootstrap *.clj > > files. I have those included in the project, so I'm not broken by > > Clojure/JVM changes. > > > Also, this code is not set up for casual play. You need to be in > > Visual Studio, download the DLR, connect Tab A to Slot B, etc. I'm > > thinking it should not be in trunk/src by the criteria you cite. > > > > This is the majority of what the ClojureScript patch changes -- moving > > > explicit uses of non-Clojure Java class names out of .clj files and > > > into clojure.lang.RT (or other appropriate Clojure classes) so that > > > the .clj can be loaded as-is. RT and Numbers have to be ported by > > > hand anyway, so it's not significantly worse on that end. > > > > I'd be very interested to compare notes and see if our needs have a > > > common solution. > > > I need to make the same kinds of changes to the *.clj files. This has > > not been automated yet, so being in synch is a matter of hand- > > editing. > > > We most definitely need to compare notes. > > > > Sounds great! But there's one very important question you didn't > > > address. What are you going to call it? :-) > > > > Seriously, though, since it seems likely that a majority of code > > > written to run on your port will not work on Clojure/JVM, because of > > > the runtime libs available (please correct me if I'm wrong), it's > > > important for a body of code to be able to clearly declare where it's > > > supposed to work. A name that is used consistently can help, I would > > > think. > > > This is 100% C#/.NET. > > > I'm up for suggestions on the name. The obvious ones: > > > - Clojure.net > > - ClojureCLR > > - IronClojure (paralleling IronPython/IronRuby, unless MS has Iron > > trademarked.) > > - CLjR (too cute) > > > Perhaps Rich will have a preference. He'll have to live with it > > longer than anyone and has branding/confusion issues to keep in mind. > > > -- David --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
