Re: Is it possible in theory to write/modify a Clojure compiler that doesn't
All~ There was a presentation at the JVM language summit about this exact topic. http://wiki.jvmlangsummit.com/Mixed_language_project_compilation_in_Eclipse:_Java_and_Groovy http://wiki.jvmlangsummit.com/Mixed_language_project_compilation_in_Eclipse:_Java_and_GroovyIn fact, the person was looking for more people to help contribute implementations for other languages to work together on this. Matt On Sun, Aug 29, 2010 at 5:44 PM, Robert McIntyre r...@mit.edu wrote: I don't think two pases is enough. What if a clojure file uses reflection (with macros of course) on a compiled java file to generate classes, sort of like how lancet works but generating classes instead of functions? And then those classes are used from other clojure and java files. Oh, and then another clojure file does the same reflection based junk to make more classes, from the classes that were generated from the first clojure file. These classes are, of course, used by other java and clojure files. In this case the only way I can think to compile everything (and sadly I'm doing something like this on my current project in lieu of a better way) is to: try to compile all the java files first (fail at some), try to compile all the clojure files (fail at some), try to compile all the java files (fail at some, but a little bit less than the first time), repeat until bytecode-level quiescence. The clojure compiler and java compiler will at most have to be invoked something like n times where n is the total number of source files in the project in certain pathological conditions as above. However, no matter what crazy stuff they're doing, as long as there no circular dependencies I think I can prove that this process will always make progress and converge to a steady state. I can make a concrete example of this condition if anyone's interested (at least I think I can!) As wasteful as it sounds is it really that bad? If the compilers only tried files that weren't already compiled and had minimal startup time then this sort of oscillation can be continued until quiescence is reached and will only take around the same time as single pass over all files. I've screwed around with this a lot and think that it would be a triumph if clojure and java could be intermixed freely. Then, there are no barriers to rewriting just one piece of a tightly interconnected java program in clojure for greater clarity/efficiency. You can just replace one java file with one clojure file, and use a java-clojure aware compiler instead of pure javac. I dream of the day where you could do this in a streamlined way in eclipse, so that everyone else on the project can focus on the concepts behind the program, not trivial minutiae like compile order. --Robert McIntyre On Sun, Aug 29, 2010 at 4:46 PM, Meikel Brandmeyer m...@kotka.de wrote: Hi, Am 28.08.2010 um 19:09 schrieb Michał Marczyk: I'm sure I'm missing lots of things, but I'd love to know which, so -- please let me know. :-) In fact, your two-pass scenario is probably the best you can get, since you can define arbitrary classes in arbitrary namespaces. (Whether this is advisable is a different question!) So any compiler trying to translate a classname to a defining namespace must fail in general. This could only be remedied by following a convention of one class per namespace which is quite a restriction. Just scanning the source files will also fail, because classes might be generated by macros. And macros might to depend on arbitrary functions defined in the file. So they can only be expanded by loading the file and executing the functions. Hence you cannot discover class generation in general. So I would suspect that your two pass scenario is a strict limit. Sincerely Meikel -- 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- 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 Note that posts from new members are moderated - please be patient with your
Re: Is it possible in theory to write/modify a Clojure compiler that doesn't
Robert, The only problem with this approach is that there ARE practically guaranteed to be circular references. If the goal is to compile Clojure as if it were Java, circular references must be accounted for. But dependencies on classes generated based on parsing bytecode... that seems a pretty extreme edge case. Not to say that it won't ever happen, but I think it would be reasonable to say that anyone doing that should roll their own build process, and not expect a standard one to work by default. I know most Java compilers would choke if I pulled this sort of shennanigans. This actually sounds a lot like generating classes via Java annotations... but even there, you wouldn't hardcode a direct reference to a generated class. You reference an interface which is defined in the normal way, and then have some sort of dependency injection to look up and inject an instance of the generated class. On Aug 29, 5:44 pm, Robert McIntyre r...@mit.edu wrote: I don't think two pases is enough. What if a clojure file uses reflection (with macros of course) on a compiled java file to generate classes, sort of like how lancet works but generating classes instead of functions? And then those classes are used from other clojure and java files. Oh, and then another clojure file does the same reflection based junk to make more classes, from the classes that were generated from the first clojure file. These classes are, of course, used by other java and clojure files. In this case the only way I can think to compile everything (and sadly I'm doing something like this on my current project in lieu of a better way) is to: try to compile all the java files first (fail at some), try to compile all the clojure files (fail at some), try to compile all the java files (fail at some, but a little bit less than the first time), repeat until bytecode-level quiescence. The clojure compiler and java compiler will at most have to be invoked something like n times where n is the total number of source files in the project in certain pathological conditions as above. However, no matter what crazy stuff they're doing, as long as there no circular dependencies I think I can prove that this process will always make progress and converge to a steady state. I can make a concrete example of this condition if anyone's interested (at least I think I can!) As wasteful as it sounds is it really that bad? If the compilers only tried files that weren't already compiled and had minimal startup time then this sort of oscillation can be continued until quiescence is reached and will only take around the same time as single pass over all files. I've screwed around with this a lot and think that it would be a triumph if clojure and java could be intermixed freely. Then, there are no barriers to rewriting just one piece of a tightly interconnected java program in clojure for greater clarity/efficiency. You can just replace one java file with one clojure file, and use a java-clojure aware compiler instead of pure javac. I dream of the day where you could do this in a streamlined way in eclipse, so that everyone else on the project can focus on the concepts behind the program, not trivial minutiae like compile order. --Robert McIntyre On Sun, Aug 29, 2010 at 4:46 PM, Meikel Brandmeyer m...@kotka.de wrote: Hi, Am 28.08.2010 um 19:09 schrieb Michał Marczyk: I'm sure I'm missing lots of things, but I'd love to know which, so -- please let me know. :-) In fact, your two-pass scenario is probably the best you can get, since you can define arbitrary classes in arbitrary namespaces. (Whether this is advisable is a different question!) So any compiler trying to translate a classname to a defining namespace must fail in general. This could only be remedied by following a convention of one class per namespace which is quite a restriction. Just scanning the source files will also fail, because classes might be generated by macros. And macros might to depend on arbitrary functions defined in the file. So they can only be expanded by loading the file and executing the functions. Hence you cannot discover class generation in general. So I would suspect that your two pass scenario is a strict limit. Sincerely Meikel -- 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 Note that posts from new members are moderated - please be patient with your first post. 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 -- 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 Note that posts from new members are moderated - please be patient with
Re: Is it possible in theory to write/modify a Clojure compiler that doesn't
Has anyone actually implemented this sort of placeholder strategy before? --Robert McIntyre On Sat, Aug 28, 2010 at 3:04 PM, Michael Wood esiot...@gmail.com wrote: On 28 August 2010 19:27, Michał Marczyk michal.marc...@gmail.com wrote: On 28 August 2010 19:19, Luke VanderHart luke.vanderh...@gmail.com wrote: I'm not just talking about class hierarchy dependencies, but also reference dependencies. Ah, I see. In that case, maybe generate placeholders for all the classes to be implemented in Clojure (with all methods doing something like throw new RuntimeException()), compile those stubs with javac together with all the Java classes, then discard the placeholder .class files and compile the Clojure classes? I believe this discussion has been had before with similar conclusion. -- Michael Wood esiot...@gmail.com -- 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 Note that posts from new members are moderated - please be patient with your first post. 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 -- 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 Note that posts from new members are moderated - please be patient with your first post. 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
Re: Is it possible in theory to write/modify a Clojure compiler that doesn't
Hi, Am 28.08.2010 um 19:09 schrieb Michał Marczyk: I'm sure I'm missing lots of things, but I'd love to know which, so -- please let me know. :-) In fact, your two-pass scenario is probably the best you can get, since you can define arbitrary classes in arbitrary namespaces. (Whether this is advisable is a different question!) So any compiler trying to translate a classname to a defining namespace must fail in general. This could only be remedied by following a convention of one class per namespace which is quite a restriction. Just scanning the source files will also fail, because classes might be generated by macros. And macros might to depend on arbitrary functions defined in the file. So they can only be expanded by loading the file and executing the functions. Hence you cannot discover class generation in general. So I would suspect that your two pass scenario is a strict limit. Sincerely Meikel -- 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 Note that posts from new members are moderated - please be patient with your first post. 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
Re: Is it possible in theory to write/modify a Clojure compiler that doesn't
I don't think two pases is enough. What if a clojure file uses reflection (with macros of course) on a compiled java file to generate classes, sort of like how lancet works but generating classes instead of functions? And then those classes are used from other clojure and java files. Oh, and then another clojure file does the same reflection based junk to make more classes, from the classes that were generated from the first clojure file. These classes are, of course, used by other java and clojure files. In this case the only way I can think to compile everything (and sadly I'm doing something like this on my current project in lieu of a better way) is to: try to compile all the java files first (fail at some), try to compile all the clojure files (fail at some), try to compile all the java files (fail at some, but a little bit less than the first time), repeat until bytecode-level quiescence. The clojure compiler and java compiler will at most have to be invoked something like n times where n is the total number of source files in the project in certain pathological conditions as above. However, no matter what crazy stuff they're doing, as long as there no circular dependencies I think I can prove that this process will always make progress and converge to a steady state. I can make a concrete example of this condition if anyone's interested (at least I think I can!) As wasteful as it sounds is it really that bad? If the compilers only tried files that weren't already compiled and had minimal startup time then this sort of oscillation can be continued until quiescence is reached and will only take around the same time as single pass over all files. I've screwed around with this a lot and think that it would be a triumph if clojure and java could be intermixed freely. Then, there are no barriers to rewriting just one piece of a tightly interconnected java program in clojure for greater clarity/efficiency. You can just replace one java file with one clojure file, and use a java-clojure aware compiler instead of pure javac. I dream of the day where you could do this in a streamlined way in eclipse, so that everyone else on the project can focus on the concepts behind the program, not trivial minutiae like compile order. --Robert McIntyre On Sun, Aug 29, 2010 at 4:46 PM, Meikel Brandmeyer m...@kotka.de wrote: Hi, Am 28.08.2010 um 19:09 schrieb Michał Marczyk: I'm sure I'm missing lots of things, but I'd love to know which, so -- please let me know. :-) In fact, your two-pass scenario is probably the best you can get, since you can define arbitrary classes in arbitrary namespaces. (Whether this is advisable is a different question!) So any compiler trying to translate a classname to a defining namespace must fail in general. This could only be remedied by following a convention of one class per namespace which is quite a restriction. Just scanning the source files will also fail, because classes might be generated by macros. And macros might to depend on arbitrary functions defined in the file. So they can only be expanded by loading the file and executing the functions. Hence you cannot discover class generation in general. So I would suspect that your two pass scenario is a strict limit. Sincerely Meikel -- 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 Note that posts from new members are moderated - please be patient with your first post. 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 -- 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 Note that posts from new members are moderated - please be patient with your first post. 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
Is it possible in theory to write/modify a Clojure compiler that doesn't
For the past week or two, I've been investigating what it would take to write something that would allow *.clj and *.java files to seamlessly compile together, such that they could be freely intermixed in a project. I knew it was a difficult problem, but I think the adoption benefits would be substantial, and the benefits huge for those stuck in Java-land at work. My conclusion (and *please* tell me if I'm missing something) is, unfortunately, that the problem requires full compiler support from both ends. Either a new compiler needs to be written that can compile both Clojure and Java, or the existing Java/Clojure compilers need some fairly extensive patching to make this possible, to share a dependency graph and symbol tables. The exception would be if it were possible to simply pass through class references when compiling *.clj files to *.class files, and not resolve them until run-time (or perhaps a seperate resolution phase of the compile process, for more compile-time safety). I realize this can't be done for dependencies between Clojure source files, since macro definitions are required at compile time. But is there any reason you couldn't do this for Java references from Clojure files? Then, it'd be very easy - just compile all the Clojure, put the classes in the classpath, and compile the Java. Any thoughts? -- 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 Note that posts from new members are moderated - please be patient with your first post. 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
Re: Is it possible in theory to write/modify a Clojure compiler that doesn't
My apologies, the title got cut off. It should be: Is it possible in theory to write/modify a Clojure compiler that doesn't resolve Java references? On Aug 28, 12:50 pm, Luke VanderHart luke.vanderh...@gmail.com wrote: For the past week or two, I've been investigating what it would take to write something that would allow *.clj and *.java files to seamlessly compile together, such that they could be freely intermixed in a project. I knew it was a difficult problem, but I think the adoption benefits would be substantial, and the benefits huge for those stuck in Java-land at work. My conclusion (and *please* tell me if I'm missing something) is, unfortunately, that the problem requires full compiler support from both ends. Either a new compiler needs to be written that can compile both Clojure and Java, or the existing Java/Clojure compilers need some fairly extensive patching to make this possible, to share a dependency graph and symbol tables. The exception would be if it were possible to simply pass through class references when compiling *.clj files to *.class files, and not resolve them until run-time (or perhaps a seperate resolution phase of the compile process, for more compile-time safety). I realize this can't be done for dependencies between Clojure source files, since macro definitions are required at compile time. But is there any reason you couldn't do this for Java references from Clojure files? Then, it'd be very easy - just compile all the Clojure, put the classes in the classpath, and compile the Java. Any thoughts? -- 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 Note that posts from new members are moderated - please be patient with your first post. 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
Re: Is it possible in theory to write/modify a Clojure compiler that doesn't
Providing we're happy with disallowing circular dependencies (which is what javac and clojure.lang.Compiler do anyway), I wonder if it might be possible to have a build tool invoke the appropriate compilers on a file-by-file basis, so that if foo.java depends on a class generated by bar.clj, which in turn depends on the class defined in quux.java, the compilation order is quux.java = bar.clj (at this stage target/classes/quux.class already exists) = foo.java (at this stage all the .class files generated by the compilation of bar.clj are there in target/classes)...? Alternatively, I suppose a two-pass compilation of Clojure sources might be possible: (1) compile all Clojure code in a way heavily reliant on reflection for all method calls on classes outside the base library, disregarding all type hints and such; (2) compile the Java code; (3) compile the Clojure code again, hopefully producing more performant, less reflection-heavy bytecode. I'm sure I'm missing lots of things, but I'd love to know which, so -- please let me know. :-) Sincerely, Michał -- 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 Note that posts from new members are moderated - please be patient with your first post. 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
Re: Is it possible in theory to write/modify a Clojure compiler that doesn't
I'm not just talking about class hierarchy dependencies, but also
reference dependencies.
For example:
Foo.java
class Foo {
public Bar getBar() {...}
}
Bar.java
class Bar{
public Foo getFoo() {...}
}
This is pretty common in the Java world.
What I'd like to do is have Foo be written in Java, and Bar in Clojure
(for example). Right now, I'm not aware of any way to make this work.
The two-pass compilation does sound like the right track...
interesting idea.
On Aug 28, 1:09 pm, Michał Marczyk michal.marc...@gmail.com wrote:
Providing we're happy with disallowing circular dependencies (which is
what javac and clojure.lang.Compiler do anyway), I wonder if it might
be possible to have a build tool invoke the appropriate compilers on a
file-by-file basis, so that if foo.java depends on a class generated
by bar.clj, which in turn depends on the class defined in quux.java,
the compilation order is quux.java = bar.clj (at this stage
target/classes/quux.class already exists) = foo.java (at this stage
all the .class files generated by the compilation of bar.clj are there
in target/classes)...?
Alternatively, I suppose a two-pass compilation of Clojure sources
might be possible: (1) compile all Clojure code in a way heavily
reliant on reflection for all method calls on classes outside the base
library, disregarding all type hints and such; (2) compile the Java
code; (3) compile the Clojure code again, hopefully producing more
performant, less reflection-heavy bytecode.
I'm sure I'm missing lots of things, but I'd love to know which, so --
please let me know. :-)
Sincerely,
Michał
--
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
Note that posts from new members are moderated - please be patient with your
first post.
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
Re: Is it possible in theory to write/modify a Clojure compiler that doesn't
Oh, I also think that mixing and matching Clojure Java modules -- groups of namespaces / classes which would be share a single build artifact -- is already fairly simple, whereas I'm not sure if mixing and matching at the level of individual source files -- with dependency chains like foo.java - bar.clj - quux.java - wibble.clj - wobble.java - ... -- is even desirable. :-) Still, my initial reaction is that this should be doable at the build tool level, with the purely reflective compilation thing probably being just a crazy idea. Sincerely, Michał -- 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 Note that posts from new members are moderated - please be patient with your first post. 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
Re: Is it possible in theory to write/modify a Clojure compiler that doesn't
On 28 August 2010 19:19, Luke VanderHart luke.vanderh...@gmail.com wrote: I'm not just talking about class hierarchy dependencies, but also reference dependencies. Ah, I see. In that case, maybe generate placeholders for all the classes to be implemented in Clojure (with all methods doing something like throw new RuntimeException()), compile those stubs with javac together with all the Java classes, then discard the placeholder .class files and compile the Clojure classes? Sincerely, Michał -- 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 Note that posts from new members are moderated - please be patient with your first post. 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
Re: Is it possible in theory to write/modify a Clojure compiler that doesn't
On 28 August 2010 19:27, Michał Marczyk michal.marc...@gmail.com wrote: On 28 August 2010 19:19, Luke VanderHart luke.vanderh...@gmail.com wrote: I'm not just talking about class hierarchy dependencies, but also reference dependencies. Ah, I see. In that case, maybe generate placeholders for all the classes to be implemented in Clojure (with all methods doing something like throw new RuntimeException()), compile those stubs with javac together with all the Java classes, then discard the placeholder .class files and compile the Clojure classes? I believe this discussion has been had before with similar conclusion. -- Michael Wood esiot...@gmail.com -- 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 Note that posts from new members are moderated - please be patient with your first post. 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
Re: Is it possible in theory to write/modify a Clojure compiler that doesn't
This sounds very similar to groovyc: http://groovyland.wordpress.com/2009/03/03/groovyscalajava/ On Aug 28, 12:50 pm, Luke VanderHart luke.vanderh...@gmail.com wrote: For the past week or two, I've been investigating what it would take to write something that would allow *.clj and *.java files to seamlessly compile together, such that they could be freely intermixed in a project. I knew it was a difficult problem, but I think the adoption benefits would be substantial, and the benefits huge for those stuck in Java-land at work. My conclusion (and *please* tell me if I'm missing something) is, unfortunately, that the problem requires full compiler support from both ends. Either a new compiler needs to be written that can compile both Clojure and Java, or the existing Java/Clojure compilers need some fairly extensive patching to make this possible, to share a dependency graph and symbol tables. The exception would be if it were possible to simply pass through class references when compiling *.clj files to *.class files, and not resolve them until run-time (or perhaps a seperate resolution phase of the compile process, for more compile-time safety). I realize this can't be done for dependencies between Clojure source files, since macro definitions are required at compile time. But is there any reason you couldn't do this for Java references from Clojure files? Then, it'd be very easy - just compile all the Clojure, put the classes in the classpath, and compile the Java. Any thoughts? -- 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 Note that posts from new members are moderated - please be patient with your first post. 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
Re: Is it possible in theory to write/modify a Clojure compiler that doesn't
Hm, thanks for the reference to that groovy thread... an interesting read. I might take a stab at writing a *generate-stubs* patch to Clojure's compiler, just to see how hard it would be to do. Out of curiosity, if Rich or anyone on the dev team reads this, is this the sort of thing that might possibly be a candidate for inclusion into the main Clojure compiler? On Aug 28, 7:02 pm, Seth seth.schroe...@gmail.com wrote: This sounds very similar to groovyc:http://groovyland.wordpress.com/2009/03/03/groovyscalajava/ On Aug 28, 12:50 pm, Luke VanderHart luke.vanderh...@gmail.com wrote: For the past week or two, I've been investigating what it would take to write something that would allow *.clj and *.java files to seamlessly compile together, such that they could be freely intermixed in a project. I knew it was a difficult problem, but I think the adoption benefits would be substantial, and the benefits huge for those stuck in Java-land at work. My conclusion (and *please* tell me if I'm missing something) is, unfortunately, that the problem requires full compiler support from both ends. Either a new compiler needs to be written that can compile both Clojure and Java, or the existing Java/Clojure compilers need some fairly extensive patching to make this possible, to share a dependency graph and symbol tables. The exception would be if it were possible to simply pass through class references when compiling *.clj files to *.class files, and not resolve them until run-time (or perhaps a seperate resolution phase of the compile process, for more compile-time safety). I realize this can't be done for dependencies between Clojure source files, since macro definitions are required at compile time. But is there any reason you couldn't do this for Java references from Clojure files? Then, it'd be very easy - just compile all the Clojure, put the classes in the classpath, and compile the Java. Any thoughts? -- 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 Note that posts from new members are moderated - please be patient with your first post. 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
