Re: Common Lisp vs. Scheme

Glynn> We've been *surviving* without tail recursion optimisation. Glynn> Ultimately, tail recursion can always be converted to explicit Glynn> iteration, which is what you need to do in elisp if you don't want to Glynn> take a performance hit. Ray> Of course. I'm just curious how bad it really is. I assume that the Ray> performance hit is not the lack of tail-recursivion, but the Ray> exceedingly slow funcall's in elisp. It's not just performance. You also risk a stack overflow if you don't do it. Ray> Some discussions in comp.lang.lisp (or scheme?) mentioned that even Ray> though tail-recursion is equivalent to iteration, it still takes a Ray> toll on speed. 20% maybe or more? I don't remember the numbers from Ray> the tests that were done. There is only one context where this is true: When you try to emulate tail recursion *in C procedure calls* via a trampoline. Optimizing Scheme-to-C compilers get around this in most cases, however. Let me again mention that Scheme compilers are among the best-optimizing compilers for higher-level languages, and often achieve code performance comparable to C. Glynn> However, it's effectively a bug (IMHO) which we've had to work around. Glynn> It would be nice if algorithms which would naturally be implemented Glynn> using tail recursion could be written in their natural form. Ray> I guess my question is, if things were written recursively, how a big Ray> a stack would we use and would that be big enough to matter? I don't even understand the question. Tail calls don't use stack space in Scheme. Many Scheme implementations (notably RScheme and Scheme 48) are not even stack-based, but use a stack only as a cache, so its size only affects performance in a very minor way. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla