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_Groovy>In 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.com<clojure%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.com<clojure%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.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
