search for: macroexpand

I guess this is slightly offtopic, but the post about the JIT and garbage collection made me wonder why LLVM supports JIT compilation at all. It has much smaller scope for optimisation due to the speed requirements, takes more memory and causes the same work to be repeated over and over for each execution. What reason is there for anything to use JIT compilation over ahead-of-time compiling to

thomas weidner wrote: >>The reason why I ask is that I expressed an outrageous opinion at >>Supercomputing back in November, to wit, that CL is probably the best >>language suited for today's multicore problems... but I don't have the >>time to hack one of the current implementations to proove the point. > > > interesting, what makes lisp superior in this

...but was a good example of how to take an Algol-like syntax and incorporate Lisp-like macros in the d-expression paper. For other languages that feature 'eval', such as Python, the AST is relatively complex enough that macros may not ever be viable, i.e., that one could easily perform 'macroexpand-1' before 'eval'. But this is my own personal opinion. Pile on and disgree! -scooter

Scott Michel <scottm <at> rushg.aero.org> writes: > Out of curiousity, for which CL implementation is this targeted? sbcl? > Or something you're rolling? I wanted to roll out my own lisp, and maybe use some library code from existing lisps (think of loop or format). Adding an LLVM backend to an existing lisp implementation is a nice idea, but currently not planned. >