> I am not aware of any auto-parallelizing compiler that is actually > useful in practice.
Good to know - thanks. > > And this leads to another question I have about Lisp-style > > languages in general. I get the impression that in Lisp > > much of the "compiler" is Lisp code itself. Ie, layer and > > layer of macros build up towards the language that then > > actually gets "used". Does this layer upon layer of macros > > lead to inefficiencies in itself? Or is the opposite true? > > Macros are handled at compile time, so they add no run-time overhead. But isn't "compile time" sometimes _at_ runtime? Ie, if a macro is dependent on runtime information, then isn't it passed to "the compiler" which is included as part of the runtime executable, turned into bytecode, and then executed itself. That's how I thought it worked anyway. In which case, compiler efficiency is of importance. > There are efficient real-life libraries that use this approach. The > best known is probably FFTW, which consists of optimized C code > generated by functional OCaml code. I have no doubt that Clojure > could take the role of OCaml there. Of course, writing such an > optimizing library requires a significant effort. Thanks for the example. It's good to know what is possible. Cheers, Mark P. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---