From ... Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!newsfeed.direct.ca!look.ca!newsfeed.icl.net!newsfeeds.belnet.be!news.belnet.be!news2.kpn.net!news.kpn.net!nslave.kpnqwest.net!nloc.kpnqwest.net!nmaster.kpnqwest.net!nreader2.kpnqwest.net.POSTED!not-for-mail Newsgroups: comp.lang.lisp Subject: Re: Tail recursion & CL References: <87iteghyva.fsf@pps.jussieu.fr> <87n13ndwus.fsf@pps.jussieu.fr> <87eloz8417.fsf@pps.jussieu.fr> <87r8syosjs.fsf@pps.jussieu.fr> <3210249273790367@naggum.net> <87zo73fsr4.fsf@pps.jussieu.fr> Mail-Copies-To: never From: Erik Naggum Message-ID: <3211542753013083@naggum.net> Organization: Naggum Software, Oslo, Norway Lines: 43 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, 08 Oct 2001 15:12:34 GMT X-Complaints-To: newsmaster@Norway.EU.net X-Trace: nreader2.kpnqwest.net 1002553954 193.71.66.49 (Mon, 08 Oct 2001 17:12:34 MET DST) NNTP-Posting-Date: Mon, 08 Oct 2001 17:12:34 MET DST Xref: archiver1.google.com comp.lang.lisp:17512 * Juliusz Chroboczek | With all due respect, Kent, you overuse this argument. Pushing it to | its logical extreme, we have no use for a carefully drafted Common | Lisp definition, because the market will choose right anyhow. Since the argument _only_ makes sense within the framework of a standard, I fail to see how "logical" it could possibly be to drop the context and still believe you have the same argument. | Alas, the said definition does not include guarantees about tail-call | elimination are not included in that definition; I would like to see such | guarantees included in a future version. You will not see such guarantees in any future version. If you want this, there is Scheme. So much of the rest of what you argue for are signs of a Scheme freak that I also fail to see why you do not just work happily within the Scheme community instead of unhappily in the Common Lisp community? What does it do for you to whine about tail-calls and never get it? | (Another thing I would like to see are stronger guarantees about what | conditions are signalled in exceptional situations; again, I do not have | problems with my vendor here, as I can always test my implementation's | behaviour, but with the standard itself.) What do these stronger guarantees actually entail? Is it the ability to sue vendors if they decide to claim to purport to conform to a voluntary standard? If so, nobody will volunteer to conform to it. We already have vendors who think it is OK to claim to purport to something they also display a strong disdain for when push comes to shove, and which they undermine when they see an opportunity to do so, and the only thing we can do with them is expose their destructiveness and applaud their constructiveness, but the whole attitude towards the standard is that it does not matter if you violate parts of it in ways that you cannot choose to ignore. In my view, there should have been viable ways to solve these "incompatibility" problems so they could co-exist with standard ways, or even be _within_ the standard, but this is indeed the path less travelled. /// -- My hero, George W. Bush, has taught me how to deal with people. "Make no mistake", he has said about 2500 times in the past three weeks, and those who make mistakes now feel his infinite wrath, or was that enduring care?