From ... Path: archiver1.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!nreader1.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> Mail-Copies-To: never From: Erik Naggum Message-ID: <3212605764038030@naggum.net> Organization: Naggum Software, Oslo, Norway Lines: 64 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 20 Oct 2001 22:29:27 GMT X-Complaints-To: newsmaster@Norway.EU.net X-Trace: nreader1.kpnqwest.net 1003616967 193.71.66.49 (Sun, 21 Oct 2001 00:29:27 MET DST) NNTP-Posting-Date: Sun, 21 Oct 2001 00:29:27 MET DST Xref: archiver1.google.com comp.lang.lisp:18287 * Erik Naggum | Since you could wrap the entire function body in a return-from, I think | this would not be helpful. Figuring out whether a function call is in a | tail-call-mergable "position" is not helped by such use of this form. * Frode Vatvedt Fjeld | I think you misunderstood me. I'll try to spell out what I meant more | clearly. | | (defun foo (x y) | (when x | (return-from foo (bar))) | (if y (baz) | (return-from foo (bax)))) Well, _I_ think I understand your proposal better than you do yourself. :) Your proposal changes and improves exactly nothing, but just adds a false impression of something that still has be determined the same way it was before it was introduced. (defun foo (x y) (return-from foo (if x (bar) (if y (baz) (bax)))))) | Here, all of the forms (bar), (baz) and (bax) are in a tail-call-mergable | position, but only (bar) and (bax) explicitly so. I do not agree with this. Figuring out whether a function call is tail-call-mergeable is generally not possible through a trivial visual inspection. In the above form, all of the function calls are pretty obviously the last call the function will make, and if you cannot see whether a function call will yield the return value or not, it certainly will not help to have a piece of wrapper code around it that might _lie_. | Now, my suggestion was that one can rewrite your typical (tail-) | recursive function: [...] to this: [...] ..and be sure your member | function either runs in constant space or compilation will fail. My argument against your proposal is that you could wrap the entire function in this newfangled return-from form and not reduce the problem one iota. | Or the compiler will emit a warning if that is what you specify. Of | course, if the result-form is anything besides a function call, | tail-call-merging will fail. Now, this is getting so specific it looks like a _real_ kluge. How about if someone provided a compiler-macro for that function? How about a real macro? Would you really want so much of your code to fail compilation even though nothing had materially changed? In other words, if you had a form like you propose, the only place I can see it being really useful is at the _outermost_ level, like I have demonstrated above, _not_ at the innermost, terminal function call that it _might_ apply to. /// -- 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