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 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
