Per Eckerdal wrote:
To me, faster compilation times alone would be a quite big win. Compiling takes rather much time when working on larger projects with Gambit.
I think a few questions are relevant to keep in mind:
- if just compilation speed is what one wants to solve, the aim might be attainable by simply using the upcoming llvm based "clang" C compiler; - the current C based backend isn't so bad for debugging because it allows one to use C tools like gprof and gdb; not sure how that will look with llvm; - there must be a reason you're not using the interpreter during development; for me it has usually been when I was developing interfaces to C code, but exactly in those cases you actually *need* C compilation (and I expect writing a backend which uses a C compiler to compile the C bits but directly generates code for the rest would be more difficult).
There is one drawback of the C backend that I'm currently wondering whether it could be solved by creating an LLVM backend: stepping in compiled code is currently not possible from the Gambit debugger (it's possible from gdb but currently not very practical because it is missing integration with the Scheme repl for pretty-printing and other functionality, and it is stopping the whole current Gambit runtime). But there are also other possible solutions to this problem, like implementing translation of continuations from compiled code into continuations in interpreted code, or one could write a bytecode VM as additional backend.
(Stepping is something one may want to control on a finer grained basis anyway: currently if you want the stepper to jump over procedures the solution is to just compile the module containing that procedure. Some better control may be useful. (Much of such control about program behaviour (which parts are being compiled how, etc.) can be part of the layer above the core, i.e. what we are calling "module systems".))
Christian.