Heya, On Mon 02 Mar 2009 00:48, l...@gnu.org (Ludovic Courtès) writes:
>> 1) It is expected that you don't have tail recursion between >> interpreted and VM code. >> >> 2) This particular problem manifests itself in that call-with-values >> is VM code (when r5rs.scm is compiled). > > (The latter is what I meant to say in my message.) > > As for (1), I'm unsure. The issue is that as long as running code with > the interpreter is the default, people may hit this kind of problem, > which is, well, problematic. Now, I have no idea how this could be > solved without resorting to dirty hacks such as the one you suggested. Yeah. It is certainly a counterintuitive situation. The compiler recognizes both call-with-values and @call-with-values, so we could just not compile call-with-values; less nasty, but still nasty, and penalizes the vm in the (apply call-with-values ...) case. > As a side note, I think it makes sense to keep the interpreter as the > default when evaluating `.scm' files Sure, for now -- or we could do what python does, and automatically create .go files as needed (and if possible). Then it would certainly pay off over time, and the compilation time would probably be a wash because in that case the .scm probably isn't even in the disk cache. > the program is short-lived This would be the normal case > if the compiler performs smart optimizations, Hahaahaha! More seriously, I think that the bar for including optimizations in the normal compilation path will be if they actually speed up the compiler as well (since the compiler is self-compiled). Cheers, Andy -- http://wingolog.org/
