Comments on: What is Clojure-in-Clojure? http://blog.n01se.net/?p=41 theoretically unambiguous Sun, 29 Aug 2010 20:06:38 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Patrick http://blog.n01se.net/?p=41&cpage=1#comment-1236 Patrick Sun, 12 Jul 2009 09:43:42 +0000 http://blog.n01se.net/?p=41#comment-1236 Chouser: the good news is that several groups of developers are already tackling these base compatibility issues, JRuby (as I mentioned) but perhaps most notably, Fan (http://fandev.org) which aims for reliable .Net/JVM portability. I imagine some best practices will emerge as these people talk with and learn from each other. The more interesting step for me will be when they seriously tackle compiling to ECMAScript and to Parrot bytecode as well. One wonders where this will all lead... Chouser: the good news is that several groups of developers are already tackling these base compatibility issues, JRuby (as I mentioned) but perhaps most notably, Fan (http://fandev.org) which aims for reliable .Net/JVM portability. I imagine some best practices will emerge as these people talk with and learn from each other. The more interesting step for me will be when they seriously tackle compiling to ECMAScript and to Parrot bytecode as well. One wonders where this will all lead…

]]> By: Chouser http://blog.n01se.net/?p=41&cpage=1#comment-1235 Chouser Sat, 11 Jul 2009 17:41:09 +0000 http://blog.n01se.net/?p=41#comment-1235 Patrick: you're right -- to achieve anything like compatibility between the various Clojure ports will require real design decision work. Implementing the decisions hopefully won't be too hard, but trade offs and compromises will have to be made and these are never easy. ClojureCLR has already run in to some of these head-on: http://groups.google.com/group/clojure-dev/browse_thread/thread/d4286dac9f1cf8ba?hl=en Patrick: you’re right — to achieve anything like compatibility between the various Clojure ports will require real design decision work. Implementing the decisions hopefully won’t be too hard, but trade offs and compromises will have to be made and these are never easy.

ClojureCLR has already run in to some of these head-on: http://groups.google.com/group/clojure-dev/browse_thread/thread/d4286dac9f1cf8ba?hl=en

]]> By: Patrick http://blog.n01se.net/?p=41&cpage=1#comment-1234 Patrick Sat, 11 Jul 2009 11:31:52 +0000 http://blog.n01se.net/?p=41#comment-1234 I think the challenge re: portability will be implementation-specific details that Clojure depends on, e.g. how are Strings defined in the target platform, how is float arithmetic specified, what is the memory model esp as regards atomic updates, monitors, etc. At a high level it should "just work", but I know that the JRuby people, for example, have had to put a lot of work into compatibility in those sorts of cases. That said, it still reduces the problem space a great deal. I think the challenge re: portability will be implementation-specific details that Clojure depends on, e.g. how are Strings defined in the target platform, how is float arithmetic specified, what is the memory model esp as regards atomic updates, monitors, etc. At a high level it should “just work”, but I know that the JRuby people, for example, have had to put a lot of work into compatibility in those sorts of cases. That said, it still reduces the problem space a great deal.

]]>