From ... Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!npeer.kpnqwest.net!nreader3.kpnqwest.net.POSTED!not-for-mail Newsgroups: comp.lang.lisp Subject: Re: Tail recursion & CL References: <87iteghyva.fsf@pps.jussieu.fr> <87zo73fsr4.fsf@pps.jussieu.fr> <3211542753013083@naggum.net> <3211612557359956@naggum.net> <4jDDO4+sWd7EGsbKaJrm6tFaAqq4@4ax.com> <3bc3f0e5.394414087@news.callatg.com> <87669m5b8y.fsf@pps.jussieu.fr> <3bc6887a.564291097@news.callatg.com> <871yk8nc52.fsf@pps.jussieu.fr> <8bbd9ac3.0110130835.6ccb7894@posting.google.com> <87vghgcyyt.fsf@pps.jussieu.fr> <3bcd2e7a.1000063244@news.callatg.com> <3bcdb42c.1034288978@news.callatg.com> <3bd0cbd8$0$30612$9b622d9e@news.freenet.de> <3bd10346.1251147184@news.callatg.com> <2helny8vb9.fsf@dslab7.cs.uit.no> <3212581297705213@naggum.net> <2h669a8cni.fsf@dslab7.cs.uit.no> <3212605764038030@naggum.net> <3212695116153606@naggum.net> Mail-Copies-To: never From: Erik Naggum Message-ID: <3212706829871008@naggum.net> Organization: Naggum Software, Oslo, Norway Lines: 47 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Oct 2001 02:33:51 GMT X-Complaints-To: newsmaster@Norway.EU.net X-Trace: nreader3.kpnqwest.net 1003718031 193.71.66.49 (Mon, 22 Oct 2001 04:33:51 MET DST) NNTP-Posting-Date: Mon, 22 Oct 2001 04:33:51 MET DST Xref: archiver1.google.com comp.lang.lisp:18338 * Bruce Hoult | This is hardly surprising. But it obviously is, to _so_ many people. | At heart, the idea of tail-call merging comes from the observation that | if the compiler generates code like... | | jsr foo | ret | | ... then it can be replaced with: | | jmp foo I think this is a very good summary of the _actual_ issue. However, if the language mandates that it be "properly tail-recursive", there will be a lot more cases like that than if it does not mandate it, and lots of things that would make it impossible to do it, will be taken out of the language. Given that we find cases like this in our compiled code and can exploit the existing stack framework, wanting tail-call merging is harmless to the language. Given that requesting more tail-call merging on an abstract level has far-reaching consequences for the rest of the language, this means that the request is not just a desire to change these two instructions into one where they occur, but an implicit desire for all the other changes that come with it. | I guess that's not pleasing to purists, but it's good enough for me. Me too. I am perfectly happy with Allegro CL's way of separating the mergeability of tail-calls to self and to non-self. Since a tail-call to self can easily be made into a jump to a _different_ location than one would normally jump to enter a function, not the least because you know the exact argument list and can do everything you may need to do arrange for optional and keyword arguments and what-not before you jump to the real code, effectively only setting the lambda variables to new values, the complexity of unwinding the stack and all that evaporates, the stack frame can be reused, and (almost) all the complexity of a non-self tail- call is simply not there. Nonetheless, Allegro CL does an impressive job of merging non-self calls, too. It turns out to be quite useful in CLOS. /// -- Norway is now run by a priest from the fundamentalist Christian People's Party, the fifth largest party representing one eighth of the electorate. -- The purpose of computing is insight, not numbers. -- Richard Hamming