From ... Path: archiver1.google.com!news2.google.com!news1.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!news2.kpn.net!news.kpn.net!nslave.kpnqwest.net!nloc.kpnqwest.net!nmaster.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> <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> <2hwv1p7t4a.fsf@dslab7.cs.uit.no> <87n12lckt5.fsf@Samaris.tunes.org> <87wv1orgyr.fsf@Samaris.tunes.org> <878ze2s785.fsf@pps.jussieu.fr> Mail-Copies-To: never From: Erik Naggum Message-ID: <3213009062053491@naggum.net> Organization: Naggum Software, Oslo, Norway Lines: 36 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Oct 2001 14:31:04 GMT X-Complaints-To: newsmaster@Norway.EU.net X-Trace: nreader3.kpnqwest.net 1004020264 193.71.66.49 (Thu, 25 Oct 2001 16:31:04 MET DST) NNTP-Posting-Date: Thu, 25 Oct 2001 16:31:04 MET DST Xref: archiver1.google.com comp.lang.lisp:18593 * Kent M Pitman | Yes it does. * jrm@itasoftware.com | At the risk of sounding like John Cleese, ``No, it doesn't.'' I think Kent means "there is a case when it does" and that you mean "there is a case when it doesn't". The former is far more interesting than the latter, because the former has far more implications that the latter. That some problem vanish when block does not allocate is quite unimportant if those problems do not vanish if block does allocate. That it is possible to implement something a particular way that will remove a particular set of problems, does not mean that that particular way is usable within the framework that needs to cater to more than just this particular problem. This line of argument is the core of my objection to _requiring_ Common Lisp systems to do tail-call merging, because I can foresee several negative consequences of this requirement for several implementations that will impact other useful things that I want much more than I want tail-call merging. Other people have other priorities, but since there conflicts, and people can actually make do with _implementations_ that offer something they want (except for Juliusz Chroboczek, who does not want to use it, anyway), and since changing the language to force everybody to do tail-call merging carries a cost in terms of what other things become easier and harder to do -- such as an attendant reluctance to do things that make tail-call merging impossible -- the status quo is _politically_ satisfactory: Making changes will be _unsatisfactory_. /// -- 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