Hello! Andy Wingo <[email protected]> writes:
> On Mon 02 Mar 2009 00:48, [email protected] (Ludovic Courtès) writes: >> 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. Yes, but OTOH that's an unusual case, no? >> 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. That's one possibility. I think I prefer having to compile things explicitly, though. >> if the compiler performs smart optimizations, > > Hahaahaha! To put it another way, the compiler may not be designed from the ground up to minimize compilation time, whereas the interpreter (supposedly) tries to achieve this. > 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). Hey, walking in Dybvig's footsteps? ;-) http://www.cs.indiana.edu/~dyb/pubs/hocs.pdf Thanks, Ludo'.
